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The Right Attitude for the Program Manager 


by Douglas R. Broome 


The NASA experience shows that one can fol- 
low all the procedures, rules, suggestions, etc., 
discussed in a management handbook and 
still fail to meet program objectives. The prac- 
tical fact is that there is no cookbook approach 
or procedure — no specific set of decision rules 
— that, even if rigorously followed, will en- 
sure program success. The elements most 
critical to program success are instead found 
within the individuals serving as the program 
manager or program scientists. Success does 
not derive primarily from "what” is done, but 
rather by the "how” and "why” in the accom- 
plishment. Success, therefore, lies in the indi- 
vidual’s personal commitment to leadership 
and management excellence. It is this com- 
mitment that is the key to effectiveness in 
these positions. 

The question of what characteristics and attri- 
butes comprise the excellent manager or lead- 
er, regardless of the field of endeavor, evokes 
much emotion and endless opinion; it is the 
subject of literally hundreds of books. Partici- 
pation in this debate is not the purpose here. 
Rather, our primary purpose is to present and 
briefly discuss the specific characteristics and 
attributes that the leadership of the Astro- 
physics Division desires in its program man- 
agers and program scientists. We should de- 
scribe those characteristics and attributes 
which, when coupled with the appropriate use 
and application of the methodologies, proce- 
dures, aids, and suggestions presented in a 
handbook, can be expected to maximize the 
probability of successful accomplishment of 
the objectives of any program that may be as- 
signed to them. 


At first glance, the following discussion and list 
of attributes may seem to imply that the excel- 
lent science program manager, flight program 
manager, or program scientist must be super- 
human. Although outstanding performance is 
expected, perfection at all times in all things is 
not really achievable. Instead, what is expected 
is that degree of perfection necessary at the 
time to effectively resolve the issues at hand, as 
they are encountered, without the need to re- 
sort to excuses. 

||| Are You "In” or 

|jj| "Ahead of” the Crowd? 

It is an unfortunate fact that many people live 
out their lives within a set of limitations or con- 
straints of their own creation, constraints that 
unnecessarily but seriously limit their accom- 
plishments in all aspects of life. In one frame of 
reference, they live "... within their own nine 
dots;” in another, they "... live lives of quiet des- 
peration.” Others, meanwhile, seem intuitively 
or instinctively to pursue their life goals with a 
predisposition towards accomplishment and 
achievement that assures their success at al- 
most anything they try. These latter people 
seem to possess an attitude, sense or psychology 
of victory that the former do not. History dem- 
onstrates that it is from this latter group that 
the most successful leaders derive. And it is 
from this latter group that the Astrophysics Di- 
vision seeks its science and flight program 
managers and program scientists. 

Should the reader be considering (or holding) a 
position as a science program manager, flight 
program manager, or program scientist in this 
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Division, and after reading this find that he or 
she is comfortable with the views presented, 
then the working environment will probably 
be a friendly, comfortable one. Should the 
reader find some major disagreement or lack 
of "gut level” comfort with its content, then 
his or her talents would probably be better 
used elsewhere, and his or her mental peace 
and career potential better served in some 
other organization. 

As a rule, NASA normally has only a handful 
of major flight programs under way at any 
given time. These few programs, though, in- 
volve a significant portion of the agency’s re- 
sources and comprise the essence of its reason 
for existence. The program manager or pro- 
gram scientist positions for these programs 
are thus coveted. They are positions of high 
prestige and high visibility; they are also posi- 
tions that demand measures of commitment, 
devotion, responsiveness, responsibility, flexi- 
bility, courage, leadership, management, and 
technical skill well above that demanded of 
most other positions in the agency. Finally, 
they are positions that involve unusually high 
levels of pressure, "heat” and career risk. 
Though the pay is excellent for the govern- 
ment service, the pay cannot be (and normally 
is not) the reason one serves in either of them. 
The incumbents must instead derive their pri- 
mary personal and career satisfaction from 
the successful attainment of difficult goals in 
a complex environment by using the best 
combinations of people, time, dollars, facili- 
ties, and interpersonal relationships. 

IBM "Trying” Is Not Good Enough 

Because of the importance of these flight pro- 
grams to NASA’s mission, the fundamental 
mindset of the successful program manager or 
scientist must be on the achievement of excel- 
lence, and the most basic personal standard 
of performance must be the achievement of 
success. Only to have tried must be consid- 
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ered by the individual to be unacceptable per- 
formance. "I tried” cannot be enough for the 
success-oriented program manager or pro- 
gram scientist. "I sent them a memo,” "I 
wrote a memo for the record,” "I left them a 
message” — this whole approach to satisfac- 
tion of their assigned program responsibilities 
is inacceptable. Instead, the standard must be 
set on real accomplishment — on having 
achieved action, met performance, or caused 
movement, not in having "tried” to. In this 
line of work, points are not given for second 
rate or second place performance; there is no 
second place in program management — only 
success or failure. The understanding and ac- 
ceptance of this fact is the key to management 
excellence! 

This point — that "trying,” as opposed to suc- 
ceeding, is not enough — is fundamental to 
the measurement of success in the Astrophys- 
ics Division both in the management of its 
flight programs and in the management of its 
science programs. If the Astrophysics science 
and flight program managers or program sci- 
entists accept this and operate accordingly, 
then their professional lives will be exhilarat- 
ing and rewarding; they will certainly never 
be boring. On the other hand, failure in the 
ongoing, smaller things is not in itself a major 
problem. In fact, failure is one of the better 
motivators for "learning that lasts.” It is the 
making of excuses that is unacceptable, for ex- 
cuses are most often simply the lazy person’s 
rationalizations for not having put out the ex- 
tra 10 percent that is often necessary to en- 
sure success in any endeavor. 

Another major consideration for the prospec- 
tive member of an Astrophysics program team 
is this: by virtue of the organizational struc- 
ture, the science program manager, flight pro- 
gram managers, or program scientists in the 
Astrophysics Division normally command no 
one. Instead, they must convince other peo- 
ple to commit the resources of their organiza- 
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tions to the accomplishment of their objec- 
tives. To achieve this difficult task, the indi- 
viduals concerned must exercise great skill in 
developing and using effective power; that is, 
in acquiring the voluntary alignment of the 
goals of the necessary external organizations 
and people with those of their programs. 
Again, results, not effort, are the basis upon 
which performance is measured. 



What Part Does "Luck” Play? 


One final topic to be considered is "luck.” 
Coupled with the success-related attributes 
discussed below, one must also possess a large 
measure of intuitiveness, manifested in what 
is often referred to as luck. Many people be- 
lieve that luck is a gift from the gods or an act 
of nature; others believe that it is a function of 
the positions of the stars and planets (seven of 
them, anyway) at birth. The management of 
this division believes that personal luck is 
largely a consequence of behavior; that is, 
luck is in essence "made” by the individual 
through his or her attitude, beliefs, and life- 
style. Regardless of the field of endeavor, the 
demonstration of "luck,” as with the achieve- 
ment of "excellence,” seems to lie in the mind- 
set of the individual and in what lies in his or 
her heart. Its mobilizing force seems there- 
fore to originate in the attendant attitude and 
fundamental approach to life held by the indi- 
vidual. In effect, we are, or become, what we 
choose to be. 


jjjjJII The Necessary Attributes 

Specific attributes and characteristics that 
are desired in the excellent astrophysics sci- 
ence program manager, flight program man- 
ager, or scientist follow. While only the rarest 
of human beings will demonstrate all these at- 
tributes at all times, the effective manager or 
scientist will exhibit the right ones at the 
right times to solve the problems. 


1. Sense of duty. Willingness to readily 
submerge ego to the greater needs of the pro- 
gram, the user community, the agency and 
the nation; a person to whom the phrase 
"Duty is the most sublime word in the English 
language” has real meaning. 

2. Personal integrity. Possession of a sys- 
tem of ideals and standards consistent with a 
personal standard of morality beyond which 
one will not go or upon which one will not 
compromise; abhorrence of "situational mo- 
rality.” 

3. Maturity of judgment. Wisdom to know 
when and when not to speak; to fight; to stand; 
to judge; to bend or break the "rules” or regu- 
lations; and to follow or violate the estab- 
lished chains of command, information flow, 
and authority. 

4. Moral courage. Ability to determine 
when a stand must be taken, without compro- 
mise, for the good of the user community, the 
program, the agency, and one’s personal code 
of honor and standard of conduct; ability to set 
pride aside and thereby avoid or abandon un- 
tenable, unreasonable, or irrational positions 
rather than exhibit destructive behavior or 
get into positions that conflict with personal 
values (see also "Loyalty,” below); willingness 
to choose the unpopular position when con- 
vinced that that position is the "right” one. 

5. Mental and (occasionally) physical 
courage. Coolness, calmness, steadiness "un- 
der fire” or in high-pressure situations. 

6. Enthusiasm. Supportive of management 
goals and needs, especially for "quick-turn- 
around” actions or information transfer; posi- 
tive in attitude; antithetical to negativism, 
yet maintaining appropriate objectiveness; 
antithetical to cynicism; pleasant, especially 
under stress. 
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7. Loyalty (personal and organizational) 
Wisdom to understand the innate personal 
and organizational destructiveness of gossip 
and disloyalty to one’s management chain, su- 
pervisor, supervisees, or program objectives, 
with an ingrained commitment to avoid or dis- 
courage such destructive behavior (see "Moral 
courage,” above). 

8. Quick-wittedness. Ability to respond 
quickly and positively to unexpected or rapid- 
ly changing situations; "quick on your feet.” 

9. A "can-do” attitude. Ability to accept or 
act on valid management requests for action, 
however "far out,” strange or unreasonable 
they may seem, in a positive, confidence- 
inspiring manner, particularly when reaction 
or response time is short. 

10. Proactive stance. Possession of an in- 
herent propensity for self-initiated action; a 
self-starter. 

11. A "nose for problems.” Ability, when 
all "appears” well, to sense or "feel” intuitive- 
ly that something is amiss (see also the para- 
graph above concerning luck and intuition). 

12. Global thinking. Ability to consider 
events, plans, alternatives, etc., in both the 
micro- and macro- view; that is, in planning or 
in anticipating future actions or possibilities, 
the ability to identify and assess the potential 
impacts on the program and initiate the ap- 
propriate actions; the ability to develop and 
maintain a model of the program’s political 
operating environment, identifying both the 
supportive and the a dversarial groups, orga- 
nizations or institutions, or potential "stop” 
points or scenarios, or national moods, events 
or activities that could affect the program — 
pro or con — and develop appropriate plans or 
interventions to either minimize adverse im- 
pacts or to exploit favorable opportunities for 
the benefit of the program. 


13. Unwillingness to accept the status 
quo. That is, never accepting out-of-hand 
that "this is the only way it can be done” or "it 
can’t be done.” 

14. Tenacity. Indefatigability; grit; determi- 
nation; stick-to-it-iveness; unwillingness to 
accept less than that which will accomplish 
the objective; willingness to persevere in the 
face of resistance or peer pressure until satis- 
fied that the findings, conclusions, and correc- 
tive actions proposed or taken are in fact 
sound; appreciative of the difference between 
"real” action that achieves the desired results, 
and "apparent” action, represented by the 
writing of useless or ineffective memos or oth- 
er such "CYA” documents. 

15. Creativity. The ability to create order 
out of chaos; to look at a problem in light of 
the larger context of what is possible (that is, 
outside of the narrow focus of the specific de- 
tails of the problem itself) and to develop 
unique or non-obvious, straightforward solu- 
tions that achieve the supposedly impossible 
for the overall good of the program. 

16. Innate curiosity/inquisitiveness. An 
inherent attitude of "What’s this all about?”, 
"How does that work?”, 'Why do we have to 
accept that?”, "Is that the only way?”, "Is that 
really the right solution?”, etc.; constantly 
looking for problems or alternatives as a nor- 
mal way of doing business. 

17. Analytical. Through appropriate "pro- 
cess” questions, ability to determine whether 
the findings, conclusions, and corrective ac- 
tions proposed or taken are in fact sound; not 
intimidated by the assumed "expertness” of 
others, but instead driven to understand the 
logic of their recommendations or conclusions. 

18. Practical relevancy. The ability to 
identify and isolate the "real” problem from 
the "apparent” problem; ability to rapidly cut 
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through the masses of data to get to the rel- 
evant information, to separate the "wheat 
from the chaff,” to know when to look at the 
forest and when to look at the trees; ability to 
determine what is important to the solution of 
the real problem while maintaining a continu- 
ing sensitivity to any implications of this solu- 
tion to program and agency objectives and op- 
erations. 

19. Open-mindedness. Openness and will- 
ingness to listen to others; willingness, desire, 
and ability to continue learning; one who 
finds "not invented here” attitudes unaccepta- 
ble. 


iB How Do You Measure Up? 

The degree to‘ which existing or prospective- 
program managers or program scientists pos- 
sess the characteristics and attributes dis- 
cussed above cannot, of course, be measured 
objectively. Each person must, therefore, 
make a rigorously honest, objective self- 
assessment in terms of the discussions herein 
and answer the question: "For the position I 
desire, do I have 'the Right Stuff?” Be thor- 
ough in your self-assessment. Your future 
perception of your personal and professional 
success, peace of mind, serenity and, in es- 
sence, your future happiness are at stake. 


Excerpted, from ” An Introduction to Astrophysics Division Program Management: A Primer on Program Manage- 
ment Practices and Principles Used in the Astrophysics Division, Office of Space Science and Applications (OSSA), 
NASA” 2nd edition, October 1989. The document was prepared and updated at the request of Dr C Pellerin, Di- 
rector of the Astrophysics Division. 
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Mission success for the Galileo project will not be determined until December of 1995 when the spacecraft ap- 
proaches Jupiter . It was launched from Kennedy Space Center in October aboard Space Shuttle Atlantis. Even 
then , a probe will have to be released to parachute into the Jovian atmosphere before a two-year study of the planet 
and its moons begins. 
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Program Control for Mission Success 


by G. W. Longanecker 


Note: The following represents my contribu- 
tion to a panel discussion on the subject con- 
ducted at the October 4, 1989 session of 
NASA’s Advanced Project Management 
Course. My fellow panel members were Tom 
Newman and Bill Sneed. 

My first premise is that in order to exercise 
program control, you must have a controllable 
program. A controllable program is one that 
has been properly scoped technically, realisti- 
cally scheduled, and adequately budgeted. 

The first step in scoping a program is obtain- 
ing a set of minimum performance require- 
ments to meet the mission objectives. I know 
that this is a difficult task, because your cus- 
tomer is intent on achieving the maximum 
possible performance. However, my recom- 
mendation is to get an agreement with your 
customer on the minimum requirements, and 
then set the specifications to achieve a reason- 
ably increased level of performance. This will 
allow for possible descoping actions later in 
the program, should the need arise. Since our 
programs nearly always involve state-of-the- 
art technology, and with today’s emphasis on 
resource control, a good descoping plan devel- 
oped early in the program is important to 
have in your back pocket. 

The other two ingredients of a controllable 
program are schedule and cost. The two are 
very much interdependent and must be bal- 
anced with the degree of risk deemed appro- 
priate for the program. There has been a lot of 
rhetoric on the subject of risk, especially in re- 
cent years. However, in my 30 years with the 


agency, I really didn’t see much risk-taking, 
even with the unmanned scientific and appli- 
cations satellite programs. Risk is extremely 
difficult to quantify, especially when you’re 
dealing with single satellite programs. How 
do you explain a risk trade-off to a group of 
space physicists who are committing possibly 
half of their professional careers to a single 
satellite mission? 

My consummate goal was always mission suc- 
cess. What this really boils down to is that 
you need to have adequate schedule slack and 
budget contingency to solve the inevitable 
problems that will confront you along the 
way. Headquarters must hold sufficient re- 
serves to cover any changes in scope. This is 
important enough to reiterate. The project 
manager at the field Center budgets and con- 
trols reserves for problem solving; the pro- 
gram manager at Headquarters budgets and 
controls reserves for scope changes. The last 
line of defense is to descope the program. As I 
said earlier, if you have set your specifications 
with some margin over the minimum goals, 
you should have some room to descope and 
still meet mission objectives. The real chal- 
lenge for a manager is that you probably will 
have to make some descoping decisions during 
the development phase so that you have some 
remaining contingency for the test and evalu- 
ation phase, mission operations, data collec- 
tion, and data processing. 

Properly scoping a program requires that suf- 
ficient studies be performed during the defini- 
tion phase. As a rule of thumb, four to eight 
percent of the expected total run-out cost of a 
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program should be spent through phase B. In 
my experience, NASA is notorious for skimp- 
ing on definition-phase funding. When you 
skimp during phase A and phase B, you have 
an open invitation to performance, schedule, 
and budget problems during phases C and D. 
As part of the procurement planning process, 
you will develop in-house a "should-cost” esti- 
mate for the program. Your budget requests 
will be based on this "should-cost” figure plus 
contingency. Because of competition, you will 
most likely negotiate a contract for less than 
the "should-cost” estimate. The difference 
should not be considered part of your contin- 
gency for problem solving, but rather it repre- 
sents the additional funds required to realis- 
tically perform the prescribed effort without 
problems. Occasionally a contractor will pro- 
pose a scheme that should save some money, 
but again my experience has been that you 
should pay attention to your "should-cost” es- 
timate. 

Beyond the programmatic obstacles to a con- 
trollable program, the single biggest hard- 
ware obstacle in my experience has been 
piece parts. I can’t remember a single pro- 
gram (and I’ve launched 21 satellites) where 
we didn’t have problems with piece parts. 
We’d design a circuit, breadboard it, test it 
and then find that we couldn’t get flight- 
qualified versions of the parts. We also suf- 
fered from being a small-volume user of piece 
parts since most of our programs involved a 
single satellite. The only advice I can offer is 
to use standard parts as much as possible in 
your designs, order your parts as early as pos- 
sible in the program, and look for second- 
source suppliers for your critical parts. Even 
after doing all of the above, the odds are that 
you will have piece part delivery problems. 

As for program control, there are many good 
techniques and tools. Everything starts with 
a good work breakdown structure (WBS). 
You will have developed one during the defi- 


nition phase and for the phase C and D pro- 
curement package and, subsequent to contract 
award, will agree to the WBS with your prime 
contractor. The WBS is the basis for your 
schedule projection and budget estimate. It 
must have sufficient granularity to identify 
the critical elements or building blocks of the 
program. 

Your schedule must have slack identified at 
critical points in the program. It is not suffi- 
cient to carry all the slack in the period just 
before the launch readiness date. This is espe- 
cially true when you’re dealing with intergov- 
ernmental or international partners in a coop- 
erative program. In most cases you’ll find 
that the cooperating agencies have even less 
flexibility to deal with schedule and budget 
changes than we do in NASA. Once estab- 
lished, the schedules can be tracked by any 
number of computer-generated systems. 
Critical paths are easily identified and 
tracked. However, I advise you not to rely 
solely on the automated schedule systems. 
I’ve always found it useful to prepare a few 
charts on critical elements that I could update 
manually to look for schedule trends. My fa- 
vorite is one that tracked on a monthly basis, 
for a few selected milestones, the currently 
planned date versus the originally scheduled 
date (Figure 1). I would frequently find that I 
could apply the slope of the trend for interme- 
diate milestones to forecast the most probable 
completion date for a downstream event, even 
though the contractor continued to forecast 
the original event date. I found it easier to 
look at my few graphs than to study the 
computer-generated charts covering the walls 
of the "war room.” You have to keep a per- 
spective on the big picture. 

The final element of program control that I 
wish to discuss is a performance measurement 
system (PMS). A PMS, or earned value sys- 
tem, allows you to track progress versus ex- 
pended resources compared to your plan. Es- 
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Figure 1. - Sample "Trend” Chart 


sentially all major contractors have a PMS 
that they use for their programs. The key 
word here is "use.” Having a PMS in your 
contract is a useless exercise if the contractor 
is not actually using the system to help man- 
age the program. Accordingly, you should 
adopt the system your contractor is familiar 
with, rather than insist on a similar but dif- 
ferent system. Due to the nature of our busi- 
ness, changes to the program baseline are to 
be expected. Obviously, such changes should 
be kept to the absolute minimum, but when 
it’s unavoidable, any significant change must 
be quickly incorporated into the PMS. 


Reporting earned value against an outdated 
plan is useless at best. It can be worse than 
useless if someone believes data that is blind- 
ly cranked out, based on an outdated plan. If 
the data is current, a PMS can help you de- 
tect the trouble spots sooner and, therefore, 
direct your problem-solving energies more 
efficiently. 

As is the case with automated scheduling 
systems, PMS is not a panacea for the man- 
agers. You have to keep track of the big pic- 
ture, and above all, use good old common 
sense. 
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GOES-G, launched on a Delta 1 78 in 1986 , was built for the National Oceanic and Atmospheric Administration. 
The satellite is an improved version of geostationary meteorological spacecraft providing day and night pictures, 
plus vertical temperature and moisture data in the atmosphere for weather forecasting. Current GOES projects 
have PMS requirements that are tested and refined for better program control. 
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Performance Measurement: A Tool for Program Control 


by Nancy Abell 


The NASA program and project managers of 
the 1990s will continue to work in the envi- 
ronment of constrained resources in terms of 
reduced budgets, limited staffing, and tight 
schedules. In a speech to the Explorers Club 
in January 1989, former NASA Administra- 
tor James Fletcher stated: "The funds being 
requested do not permit us the luxury of back- 
ups, of alternatives, of programmatic robust- 
ness. Virtually every element of the program 
is being pursued on a success schedule — and 
we know in advance that there will be unfore- 
seen technical problems to solve and dilem- 
mas to face which will require internal adjust- 
ments and constraints.” In this environment 
there are focused efforts to improve program 
and project management. One potentially 
powerful tool available to the project manager 
which has been used successfully in many 
government agencies is performance mea- 
surement. 

Performance measurement is a management 
tool for planning, monitoring, and controlling 
all aspects of program and project manage- 
ment — cost, schedule, and technical require- 
ments. It is a means (concept and approach) to 
a desired end (effective program planning and 
control). To reach the desired end, however, 
performance measurement must be applied 
and used appropriately, with full knowledge 
and recognition of its power and of its limita- 
tions — what it can and cannot do for the 
project manager. 

Performance measurement is not a new con- 
cept to the government or to the aerospace in- 
dustry. It has its origins in the Department of 
Defense (DoD) programs of the 1960s. Inter- 


est and application of the performance mea- 
surement concept spread to other government 
agencies in the 1970s and 1980s. Today per- 
formance measurement is being applied to 
major programs of the DoD, National Security 
Agency, Department of Energy, Federal Avi- 
ation Administration, and NASA. Perfor- 
mance measurement is widely endorsed as a 
valid approach to controlling contract perfor- 
mance. 

The Goddard Space Flight Center (GSFC) has 
been implementing performance measure- 
ment system (PMS) requirements since 1983 
on major research and development (R&D) 
contracts with a price of $25 million or more 
and a period of performance longer than one 
year. GSFC’s PMS policy was established by 
the Center director to provide for consistent 
application on all major Center acquisitions. 
Use of performance measurement is also en- 
couraged on R&D contracts in the $10-25 mil- 
lion range, but applied on a case-by-case basis. 
GSFC currently has 12 contracts in various 
project phases that have PMS requirements. 
With the large number of major independent 
spacecraft and instrument development con- 
tracts at GSFC, such as the various meteoro- 
logical spacecraft and instruments of the 
Geostationary Operational Environmental 
Satellite and Television and Infrared Obser- 
vational Satellite programs, we have had the 
opportunity to continually improve our imple- 
mentation of PMS through a "lessons learned” 
approach. Many project managers have had 
the opportunity to test the effectiveness of this 
management tool. At GSFC, some of the more 
effective PMS applications have been on the 
Gamma Ray Observatory and the Tracking 
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Figure 1. - Traditional Plan vs. Actual Technique 


and Data Relay Satellite System spacecraft 
contracts. 

What is the potential of this management 
tool? What does performance measurement 
do that a traditional plan vs. actual technique 
cannot do? Performance measurement pro- 
vides an improvement over the customary 
comparison of how much money was spent (ac- 
tual cost) vs. how much was planned to be 
spent based on a schedule of activities (work 
planned). This commonly used plan vs. actual 
comparison, however, does not allow one to 
know from the numerical data if the actual 
cost incurred was for work intended to be 
done. With performance measurement, actual 
work progress (work done, also known as 
earned value) is quantified by an objective 
measure of how much work has been accom- 
plished on the program. This added dimen- 
sion of a quantitative assessment of work ac- 
complished allows for comparisons to be made 


between the value of work that was done vs. 
the work that was planned to be done (sched- 
ule variance). It also allows for a comparison 
of the actual cost of work that was done vs. the 
planned value of the work that was done (cost 
variance). This analysis then provides for ear- 
ly identification and quantification of cost and 
schedule problems. 

A graphic depiction of the data available from 
the traditional plan vs. actual technique com- 
pared to those available from a performance 
measurement system may serve to more clear- 
ly illustrate the concept. A hypothetical 
spacecraft program is expected to take five 
years to build at a cost of $500 million. Figure 
1 shows the traditional plan vs. actual tech- 
nique. If "time now” is the completion of year 
2, the graph indicates that we had planned to 
spend $250 million. The actual cost (i.e., time 
card charges, material expenses, etc.) reported 
to the government is $200 million. 
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Figure 2. - Performance Measurement Technique 


What can a project manager conclude from 
this information? Is it possible to determine if 
this program is overrunning or underrun- 
ning? With this limited information avail- 
able, a project manager may assume that the 
contract is underrunning and would have no 
basis to question the assumption that this pro- 
gram will underrun at completion. At a mini- 
mum it currently appears that the $500 mil- 
lion funding estimate is adquate to complete 
this effort. 

In Figure 2 an additional data point has been 
added to the same hypothetical spacecraft pro- 
gram. The contractor has assessed the value 
of the work accomplished (or earned value) to 
date. This new information reveals that of the 
$250 million of work planned to be done to 
date, only $150 million has been done. Some 
work that was planned to be done has not been 
done and is reflected as a $100 million sched- 
uled variance. Also the $150 million worth of 


work done can be compared with the actual 
cost of $200 million. This comparison shows 
the planned value of the work vs. the actual 
cost of that same piece of work. Now the pro- 
ject manager can see that this program is ac- 
tually overrunning by $50 million to date. We 
now have enough data to question the validity 
of the $500 million funding estimate for com- 
pletion of this effort. We can begin to see that 
this program is headed for an overrun of costs 
at completion along with potential schedule 
slippage. 

As a result, the project manager having the 
PMS data available in Figure 2 is better able 
to estimate early the total costs and projected 
period of performance of this program, there- 
fore avoiding being surprised by an overrun 
much later in the program. If the data yield a 
"doom and gloom” assessment, there is oppor- 
tunity to make decisions early to avoid an ap- 
proach that is too costly or that takes too long. 
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The basic objective of performance measure- 
ment systems is to provide a suitable basis for 
responsible decision-making by both the con- 
tractor and the government management by 
ensuring that (1) the contractor is using effec- 
tive internal cost and schedule management 
control systems and that (2) the government 
can rely on valid, timely, and auditable data 
to be produced by those systems to determine 
program status. 


Unfortunately there has not been a consistent 
experience within the agency regarding PMS 
implementation. Personnel at various NASA 
Centers and in the aerospace industry believe 
that while some NASA applications of PMS 
have been successful and effective, other at- 
tempts to use PMS as a management tool have 
actually been counterproductive. In some in- 
stances, performance measurement systems 
have not always provided accurate reporting 
of cost and schedule status, and there are dif- 
fering opinions about why PMS did not work 
in these instances. The most prevalent of 
these is that in the NASA environment and 
culture, a disciplined approach to program 
management is not appropriate or applicable. 
While it is healthy to question the worth and 
applicability of PMS for NASA programs, it is 
also beneficial to explore some of the common- 
sense features of PMS that have proven effec- 
tive in controlling project costs and schedules 
in many government agencies for the past 22 
years. 



Some Basic Principles 


Performance measurement can work for you if 
you apply some basic principles. 


1. Plan the entire contractual effort. It is 
essential to plan the work for the entire period 
of performance. Near-term work is planned in 
detail while future work can be planned at a 
summary level. Failure to recognize all of the 
work to be done makes it impossible to prop- 


erly allocate resources. Programs could con- 
sume too many of the resources on the near- 
term work and not leave enough to do the 
work downstream. 

2. Maintain baseline integrity. The mea- 
surement of actual conditions against a disci- 
plined or controlled plan reveals performance 
trends that can help to predict future condi- 
tions and to determine a future course of ac- 
tion. 

3. Determine accomplishment at the level 
at which the work is performed. Who can 
better assess the work that has been done and 
the work remaining to be done than the man- 
ager responsible for performing the work? 

4. Measure accomplishment objectively. 
The most valuable status assessment of a 
piece of work is based on pre-defined miles- 
tones as opposed to personal feelings and prej- 
udices lacking reality or substance. 

5. Summarize for higher levels of man- 
agement. While accomplishment is assessed 
at a relatively low level, summary reporting 
to higher levels of management, where re- 
sources are made available, is also essential 
for control. 

6. Analyze variances and forecast im- 
pact. Variances are simply indications that 
actual conditions are different from the origi- 
nal assumptions, and variances may indicate 
the existence of current or potential problems. 
Analysis of the variances allows management 
to correct problems or to redirect efforts to 
avoid potential problems, as well as to project 
cost at completion. 

In summary, the concept of performance mea- 
surement is good, common sense program 
management that NASA project managers 
have always practiced, but perhaps not in a 
formal way. 
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||l| Specifying Customer Requirements 

NASA authority for performance measure- 
ment is based on the agency requirement 
specified in NASA Management Instruction 
9501.1 "NASA Contractor Financial Manage- 
ment Reporting System” and NASA Hand- 
book 9501.2B Procedures for Contractor Re- 
porting of Correlated Cost and Performance 
Data . The NASA Form 533P (where "P” re- 
presents performance) has been used by con- 
tractors to report performance data to NASA, 
unless the contractor has another format that 
serves as the equivalent. The 533P is essen- 
tially a minimum NASA requirement for data 
reporting purposes only. It does not require 
that an identifiable system or set of subsys- 
tems support the data. As the contractors are 
free to generate data in any way they desire, 
there is the high potential for invalid or mis- 
leading data if this is the only requirement 
placed on a contractor related to performance 
measurement. Without a system requirement 
for visibility and control of the baseline, for 
objectivity in measuring accomplishment, or 
for discipline in forecasting estimates to com- 
pletion, then performance measurement may 
not yield valuable information. While data 
can be reported on a 533P, a more disciplined 
approach to the management system is need- 
ed to identify some rules for performance mea- 
surement systems. These rules are known 
within the government and aerospace indus- 
try as the "criteria.” 

The performance measurement criteria do not 
identify a specific management control system 
to be applied to a program; but rather, they re- 
present a set of standards against which to 
measure the acceptability of a contractor’s 
cost and schedule control system. There is, in 
fact, a variety of equally effective ways for 
contractors to meet the criteria requirements. 
The criteria allow a company to organize in 
any way that suits the company’s philosophy 
and style. The criteria also allow a company 
to develop any desired policies, procedures, or 


methods that meet the requirements. The cri- 
teria address the age-old questions of any pro- 
ject manger: What work is to be done? Who 
will do it? When is it going to be done? How 
much will it cost? Where is the program 
heading? What has changed? The contractors 
address these questions through their man- 
agement systems’ integrated set of subsys- 
tems. These are subsystems that would be re- 
quired to manage a program whether or not a 
performance measurement requirement was 
imposed. Performance measurement criteria 
simply require that a more disciplined ap- 
proach be applied to each subsystem. The 
PMS subsystems are (1) work authorization, 
(2) budgeting, (3) scheduling, (4) data accumu- 
lation, (5) variance analysis and estimate at 
completion, (6) subcontract and material con- 
trol and accountability, (7) indirect expense 
management, and (8) change baseline control. 
PMS, then, does not address just the account- 
ing system, but rather it addresses the inte- 
grated set of subsystems that constitute all 
elements of program planning and control. 



A Good Management System 


The key to the power of performance measure- 
ment is that performance measurement data 
are only as valid as the management system 
that provides them. If a contractor operates a 
sound internal management system , the cus- 
tomer should be able to extract summary data 
from that system that reflect project status. 
To have a valid management system applied 
to NASA work in contractor plants, several 
conditions need to be met. 


First, a management commitment from the 
top down is required — all levels of manage- 
ment support are essential. It is not enough to 
have project financial or resources support 
personnel discussing PMS with the contrac- 
tor. The involvement of technical personnel is 
critical. PMS involves all aspects of program 
management and needs to be viewed in this 
way by NASA project and functional manage- 
ment personnel to be effective. 
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Second, management system discipline must 
be stressed and required. While it may be de- 
sirable to maintain a spirit of cooperation and 
non-adversarial relations with our contrac- 
tors, PMS is not of any value without a disci- 
plined approach to management. Without a 
requirement for the contractor to maintain a 
baseline, to apply objective techniques for per- 
formance measurement, or to reliably forecast 
the cost to completion, there can be no confi- 
dence in the value of the data that the man- 
agement system generates and that the con- 
tractor reports to NASA on a monthly basis. 

Third, use of data generated by the PMS is 
essential. A few simple mathematical formu- 
las and computations yield very revealing in- 
formation about the project status and poten- 
tial future of the program. Use of data serves 
to facilitate communications internally and 
between NASA and the contractor. 

Fourth, corrective action needs to be taken 
when problems are identified. A management 
system supplies data points, not solutions. It 
provides visibility into cost, schedule, and 
technical status. A system, however, does not 
manage the project, people do. A system can- 
not eliminate schedule slippages or stop over- 
runs, but it can help the project manager to 
understand the potential impact if trends are 
allowed to continue without mid-course cor- 
rection. 

Fifth, an in-plant review of the contractor’s 
management system applied to your program 
and conducted by a NASA team of interested 
and knowledgeable technical and resources 
personnel is critical. The NASA personnel 
gain invaluable knowledge of the policies, 
methods, and procedures used by the contrac- 
tor to generate monthly status reports. By un- 
derstanding the source of the data, we can 
calibrate the validity of our monthly customer 
reports and require the contractor to revise 
procedures that do not produce valid data. 


PMS is not intended to replace traditional 
management tools — it should enhance them. 
Day-to-day program management is essential. 
In fact, if managers are relying solely on per- 
formance measurement data generated at 
month-end, they will be learning of problem 
situations much too late to be effective. Peri- 
odic status reviews, "kicking the tires,” and 
routine communication internal to the con- 
tractor and between the contractor and gov- 
ernment managers are critical in managing a 
program. PMS may identify a new problem; 
but, in most cases, it allows quantification of a 
known problem through all elements of the 
work breakdown structure and through the 
functional organizations to provide a basis for 
improved management decisions. 



Cost Effectiveness 


In times of constrained resources it is reason- 
able for managers to question the cost effec- 
tiveness of PMS. What are the benefits and 
associated costs? The question is difficult to 
answer, however, since both the benefits and 
costs are nearly impossible to quantify. 


PMS results in a better controlled project with 
improved communication, both internally and 
with the customer. To quantify the benefits is 
to ask, "What is the value of good manage- 
ment?” It is not evident how a cost savings (or 
cost avoidance), a shortened schedule, or im- 
proved technical performance through correc- 
tive action can be clearly associated with re- 
sults or a specific cost. 


The costs of PMS have also defied quantifica- 
tion for 22 years. The PMS-unique costs on 
the total contract cannot be separately identi- 
fied from the management costs that would be 
incurred in any case. They are not routinely 
collected by contractors, nor is it considered 
practical to do so. This was illustrated in a 
1987 survey of GSFC contractors who had im- 
plemented a PMS requirement. In the survey, 
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some contractors suggested that the costs of 
PMS beyond the usual management costs may 
be expressed as a percentage ranging from 2 
percent to 6 percent of total contract costs. In 
each case, however, the contractor could not 
substantiate the percentage. It was someone’s 
"non-scientific estimate,” as stated by one con- 
tractor. Surveys conducted by the DoD show 
that there is no correlation between the cost of 
PMS and the contract costs. 

This is not to say that there cannot be cost as- 
sociated with PMS requirements. In fact, the 
cost of implementing PMS is in direct propor- 
tion to the quality of the existing manage- 
ment system. The poorer the state of the con- 
tractor’s system, the greater the need for im- 
provement and the more it will cost to im- 
prove. Contractors who maintain discipline in 
their systems would incur very low cost for 
implementing PMS on subsequent contracts. 
If the same contractors did not maintain their 
systems, over time the cost to implement PMS 
on future contracts would be greater as the 
need for improvement becomes greater. Fur- 
ther, if there is not an existing integrated cost 
and schedule management system, the con- 
tractor will certainly incur cost to develop one. 
GSFC experience, however, has been that con- 
tractors awarded major development procure- 
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ments that contain PMS requirements are 
contractors who already have operational 
PMS systems as a result of their dealings with 
the DoD. Costs of PMS have been minimal 
compared to the significantly greater value 
added. 

There is one additional factor to consider in a 
discussion of the costs of PMS. Typical points 
of contention between the government and in- 
dustry concerning PMS implementation in- 
clude the levels of detail identified for man- 
agement and reporting, and the variance ana- 
lysis thresholds identified for customer report- 
ing. It is possible to avoid incurring unneces- 
sary cost to the government and frustration 
for the contractor by not requesting reports- 
that no one reads or uses, or "nice to have” 
items or analyses. 

In summary, with the focus on efforts to im- 
prove program and project management, 
PMS is a potentially valuable tool. Like any 
tool, however, it is only as valuable as the user 
chooses to make it. Implemented properly, 
PMS can ensure the generation of valid cost 
and schedule performance data to ease the 
manager’s decision-making process and can 
result in more effective program planning and 
control. 
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Galileo and its Inertial Upper Stage (IUS) were installed in Atlantis' payload bay at the end of August 1989. Six 
hours after launch the IUS was ignited , sending Galileo in a planetary trajectory past Venus once and Earth twice 
before swinging out to explore Jupiter , the Solar System's largest planet . SMR&QA engineers had to identify and 
analyze potential hazards related to the spacecraft's nuclear power source. 
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Managing SRM & QA Throughout 
the Project Life Cycle 


by George A. Rodney 


Program and project managers often ask me 
how they can gain maximum benefit from 
their safety, reliability, maintainability, and 
quality assurance (SRM&QA) engineering 
and technical support. My answer is that it is 
vital to develop a "team” culture within the 
program or project that includes SRM&QA 
support. Managers stand to benefit most 
when their management procedures and tech- 
niques are designed to ensure that safety, reli- 
ability, maintainability, and quality are built 
into the design plans of products and services 
up-front. They benefit least when safety, reli- 
ability, maintainability, and quality have to 
be built into the products and services at a 
later date, with the associated high costs of in- 
spection and rework as well as the consequent 
impact on schedule and budget. You cannot 
"inspect” quality in. 


• Ensuring top management leadership and 
involvement in quality; 

• Focusing on the customer and customer re- 
quirements; 

• Pursuing continuous improvement; and 

• Working towards prevention instead of cor- 
rection. 

The underlying theme of my discussion is that, 
because application of TQM principles encour- 
ages appropriate consideration of all factors (in- 
cluding SRM&QA-related ones), the end prod- 
uct or service will have safety, reliability, 
maintainability, and quality designed in, there- 
by reducing rework. The consequent impact on 
cost and schedule will show that SRM&QA can 
help conserve budget and time resources while 
ensuring safer mission performance. 


The purpose of this article is to discuss the 
role of NASA’s SRM&QA capability as a valu- 
able resource to assist program and project 
managers in managing risk throughout the 
life cycle of their programs and projects and to 
show the importance of utilizing SRM&QA re- 
sources and total quality management (TQM) 
principles to achieve excellence. The princi- 
ples embodied in the philosophy of TQM range 
from proper planning to total involvement of 
the workforce to assure quality products and 
services. Therefore, it is important to under- 
stand more fully the benefits that SRM&QA 
support has to offer. TQM principles include 
the following : 

• Creating a "team” culture characterized 
by quality, innovation, goal-setting, two- 
way communication, and participation; 



SRM&QA Support at Agency, Center, 
and Project Levels 


SRM&QA expertise spans a wide range of 
knowledge, skills, and experience available to 
the project manager throughout the life cycle. 
SRM&QA engineering and technical personnel 
at three levels assist project managers endeav- 
oring to address risk management issues dur- 
ing the design, development, implementation, 
and evaluation phases of their projects. 


At the agency level, the Office of SRM&QA at 
NASA Headquarters is responsible for develop- 
ing and implementing firmly defined agency- 
wide SRM&QA policies. These policies, found 
in a variety of NASA Management Instruc- 
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tions (NMIs) and NASA Handbooks (NHBs), 
provide a foundation for project efforts to ad- 
dress risk. The Office of SRM&QA also 
tracks and analyzes trends and provides inde- 
pendent assessments of major programs. Fi- 
nally, as NASA’s safety and mission assur- 
ance advocate, the office acts on behalf of pro- 
ject managers in helping secure resources and 
scheduling that promotes safety and mission 
assurance. 


At the Center level, each Center’s SRM&QA 
organization develops and implements its 
SRM&QA policies. It performs trend track- 
ing and analysis and provides independent 
assessments of programs and projects in a 
manner similar to the Office of SRM&QA at 
Headquarters. Also, the Center SRM&QA or- 
ganization provides project managers with 
the engineering and technical support to per- 
form the required SRM&QA design, imple- 
mentation, and evaluation functions. 


At the project level, SRM&QA personnel use 
a variety of tools and techniques, within the 
framework of agency and Center SRM&QA 
policies, to assess risk. 



SRM&QA Tools and Techniques 


Managers should become familiar with the 
tools and techniques that their SRM&QA 
support personnel use to assist them in de- 
signing and implementing product or service 
plans. Information concerning these tools 
and techniques can be gained from discus- 
sions with the supporting SRM&QA person- 
nel and by being familiar with the require- 
ments set out by the NHB 5300.4 series and 
other applicable agency and Center 
SRM&QA directives. The tools and tech- 
niques described in the following paragraphs 
are some of the principal ones with which 
managers should be familiar. 


performed on each component of a system to 
identify those components that are critical to 
the performance and safety of the crew, vehi- 
cle, or mission. The analysis includes identi- 
fying all system components, determining the 
potential modes of failure for each compo- 
nent, and recommending corrective actions. 

Critical Items List (CIL). Based on a FMEA, 
a CIL is developed, consisting of a summary of 
single critical failure points and a summary of 
redundant elements, the failure of which 
could cause loss of crew, vehicle, or mission. 
As such, the CIL contains the same informa- 
tion as the FMEA, except that it includes the 
rationale justifying retention for redundancy 
of any critical item not meeting design specifi- 
cations. 

Hazard Analysis (HA). HAs are performed 
after the FMEA/CIL and are designed to iden- 
tify, analyze, and categorize safety hazards, 
and subsequently track them to closure or res- 
olution. Closure or resolution includes elimi- 
nation of the hazard or control of the hazard 
through development of acceptable safety 
measures. 

Problem Reporting and Corrective Action 
(PRACA). PRACA is a system for reporting 
all problems (failures and unsatisfactory con- 
dition reports) and establishing the necessary 
corrective action. 

Electrical, Electronic, and Electrome- 
chanical (EEE) Parts and Mechanical 
Parts Control. These parts control systems 
are designed to control the selection, reduc- 
tion in number of types, specification, failure 
analysis, stocking and handling methods, in- 
stallation procedures, and reliability require- 
ments of EEE and mechanical parts. 

Qualitative Risk Assessment (QRA). QRA 
is a nonmathematical review of all factors af- 
fecting the safety of a system (hardware, soft- 
ware, etc.). It examines actual designs, pro- 


Failure Modes and Effects Analysis 
(FMEA). A FMEA is a systematic analysis 
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cesses, and parameters against a predeter- 
mined set of risk acceptability parameters. 

Probabilistic (or Quantitative) Risk As- 
sessment (PR A). PRA, a more rigorous engi- 
neering review than QRA, generates numeri- 
cal probabilities of risk by considering reli- 
ability and probability estimates of risk occur- 
rence. 

Risk assessment, whether qualitative risk 
categorization or quantitative risk estima- 
tion, must be followed by the evaluation of 
risk significance. It is important to note that 
numbers per se are not the most important re- 
sult from risk assessment. In fact, numbers 
can sometimes be deceiving. Program and 
project managers must keep in mind that, in 
reviewing risk assessment results, the most 
important result is an increased understand- 
ing of the system that leads to the discovery of 
ways to fix weak spots. Efforts can then be 
aimed at eliminating hazards where possible 
through redesign or through controlling ha- 
zards, by developing acceptable safety mea- 
sures, in those cases where elimination is not 
possible. 

jjj Cost, Schedule, Performance, 

;ill and Risk Management 

Sound decision-making for program and pro- 
ject managers requires assessing each deci- 
sion’s impact in three areas: cost, schedule, 
and performance. Managers face immense 
pressure to keep cost within budget, schedule 
according to plan, and performance according 
to assigned mission objectives. Therefore, 
much of their time is spent reconciling the 
three. Since there is an element of risk to bud- 
get, schedule, or performance associated with 
every decision or non-decision, managing risk 
is a primary component of this process. 

Risk, as it relates to performance, is defined as 
exposure to the chance of loss or injury to per- 


sonnel, loss or damage to equipment, or loss or 
delay to the mission. It is a function of the fol- 
lowing three factors: 

• The frequency with which a hazard oc- 
curs; 

• The potential severity of the resulting 
consequences; and 

• The probability of those consequences oc- 
curring when the hazardous situation ex- 
ists. 

We at NASA have learned all too well that 
performance failure can mean more than just 
failure to accomplish a mission objective. It 
can mean tragic loss of personnel and equip- 
ment, sometimes with long-term conse- 
quences to cost and schedule. 

Risk management is the decision-making pro- 
cess concerned with the balancing of 
performance-related risk with cost, schedule, 
and other programmatic considerations. It 
consists of the following four steps: 

• Identifying risk; 

• Assessing risk; 

• Making decisions regarding the 
disposition of risk; and 

• Tracking the effectiveness of the 
decisions made. 

Safety is defined as the measure of freedom 
from occurrence or risk of loss or injury during 
use of a system or equipment through the 
elimination or control of hazards or the reduc- 
tion of risk to an acceptable level. For exam- 
ple, SRM&QA engineers for the Galileo pro- 
gram had to identify and analyze the potential 
hazards related to the vehicle’s nuclear power 
source. These analyses helped planners to 
eliminate some hazards and develop measures 
to control others. The effectiveness of these 
controls is continuously tracked and evaluat- 
ed and change recommendations are devel- 
oped, as required. 
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Reliability is the measure of assurance that a 
system or equipment will perform as designed 
by reducing risks of failure. As the life cycle 
for NASA programs and projects lengthens, 
increasing emphasis will be placed on the in- 
creasing reliability of systems as a method of 
eliminating or controlling hazards. High reli- 
ability in the Apollo and Voyager programs 
contributed to their success. 

Maintainability is the measure of ease and ra- 
pidity with which a system or equipment can 
be restored to operational status following a 
failure or be maintained as a preventive mea- 
sure prior to failure. Increased maintainabil- 
ity contributes to managing risk since it helps 
compensate for reliability shortcomings in 
current technology. Space Station Freedom, 
with an expected life of 30 years, will require 
systems with an increased degree of maintain- 
ability since the space station cannot return to 
Earth for repair. SRM&QA support can assist 
by performing integrated logistics support 
and configuration management studies. 

Quality assurance is the measure of assurance 
that a system or equipment is produced or im- 
plemented as designed or intended through 
design review, inspection, and evaluation. 
High reliability systems are useless if they 
are not produced to high quality standards. 
For example, the quality of fasteners is be- 
coming an important quality issue of interna- 
tional proportions. Also, new nondestructive 
evaluation technology is assisting managers 
in ensuring the quality fabrication of hard- 
ware. 


Illf Conclusion — SRM&QA Contributes 
111 to Good Management 

The principles of TQM provide the foundation 
for decisions. Successful managers have 
learned the importance of continuous im- 
provement in providing products and services 
and are designing in quality to achieve excel- 
lence. Less successful ones risk dooming their 
program or project to struggling to "inspect 
quality in” and reworking problems in their 
products and services that could have been re- 
solved during the design process. 

From my standpoint, risk management is a 
decision-making process when the manager 
balances performance-related risk with cost, 
schedule, and other programmatic consider- 
ations. Stated this way, performance should 
receive somewhat greater consideration in 
the decision-making process than do cost and 
schedule, at least to the extent that acceptable 
safety and mission assurance standards are 
met. While no one wants to make decisions 
that have a negative impact on cost and sched- 
ule, cost and schedule decisions cannot result 
in the kind of loss, in terms of resources and 
equipment, that performance failures can. 

Performance objectives and mission success 
must come first, as they did in past programs 
such as Apollo, Voyager, and Viking. 
SRM&QA expertise is a critical element of the 
project team’s ability to develop solutions to 
eliminate or control risk, attaining continued 
objectives and mission successes within bud- 
get, on time, and according to specifications. 


Quality is planned in, designed in, and built in. Quality is not inspected in. Quality starts before designs are drawn 
and well before metal is bent. The main message here is that each person and organization in the program must un- 
derstand and believe in the need for quality performance from the onset of the program. You cannot wait until the 
hardware is built to decide you want quality and then attempt to "inspect” it in. I have often seen this tried, but never 
successfully or economically. Quality encompasses more than just the delivered hardware. It includes management, 
requirements, design, development, testing and documentation.. Simply stated, the quality of every person’s output 
is very important to the outcome of the program. — James B. Odom, " Guiding Principles for the Space Station Pro- 
gram,” in Issues in NASA Program andProject Management , NASA SP-6101 (1988). 
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Advantages of Cost Plus Award Fee Contracts 

by William C. Keathley 


Personal experiences in the management of 
projects and shared experiences with col- 
leagues have convinced me that a Cost Plus 
Award Fee contract is the best procurement 
vehicle for the high-tech, one-of-a-kind, devel- 
opment projects that constitute most of 
NASA’s projects. 

But, like most things, success isn’t automatic. 
It takes work to make it happen, and the suc- 
cessful implementation of award fee contracts 
is no exception. In fact, the use of this type of 
contract requires more government and con- 
tractor effort than other forms of contracts. 
But, in my opinion, it’s worth every hour 
spent. 

Over the years, I’ve collected a list of "lessons 
learned” related to the use of award fee con- 
tracts. I’ll try to articulate those lessons ade- 
quately in the following text. Keep in mind 
that I’m not speaking from the standpoint of a 
procurement officer. My observations come 
from the day-to-day use of these contracts in 
various positions I’ve held — project manager, 
director of flight projects (project manager’s 
supervisor), and fee determination official. 

An award fee contract is described as an ar- 
rangement whereby the government periodi- 
cally awards a fee consistent with the cost, 
schedule, and technical performance achieved 
by a contractor during a preset period with 
preset award fee pools. 

Ill Rationale 

Let me explain why I like award fee contract- 
ing. First, it’s the only contracting method 


where both government and contractor goals 
are closely linked. The government wants 
cost, schedule, and technical performance; the 
contractor wants profits. The better the total 
performance, the better the fees (profits) will 
be. Compare that with a fixed price contract 
where the total price (cost plus fee) is fixed. If 
the cost of a fixed price effort is underestimat- 
ed, the contractor may sometimes make ad- 
ustments that impose risks to the technical 
performance. This protects the contractor’s 
profits but imposes risk on the government’s 
goal for technical performance. Other ways 
exist for contractors to protect their fees in a 
fixed price arrangement (all of them bad for 
the government), but that subject deserves a 
separate paper. 

Second, an award fee contract has a built-in 
mechanism to conveniently alter and empha- 
size program events in order to satisfy current 
external and internal situations — and the 
government is involved in these adjustments. 
Prior to each award fee period, the govern- 
ment and contractor project managers review 
the plan for the upcoming period, agree on the 
planned events, and place the appropriate em- 
phasis on each event. Should problems arise 
(and they always do), the plan and the fee em- 
phasis can be adjusted accordingly. This is 
considered by most project managers to be the 
most important feature of award fee contracts. 
And while I’m on adjustments, I’d like to men- 
tion the use of "rollovers,” in which lost fee 
from prior periods is used to "sweeten the pot” 
on future events that have become so critical 
that additional emphasis is warranted. Roll- 
over is a powerful award fee tool to motivate 
contractors if used properly. 


23 


Advantages of Cost Plus Award Fee Contracts 

Lmiiuiuuin mLmummiuLLLUuiuLLumuLUTmTuuuitL - a r iTnumuuuuuutniLULULanuuuui r c T r rT 


Third, the award fee process demands good 
communication between the government and 
contractor participants. And every project 
manager knows — or should know — that 
good communication is a necessary ingredi- 
ent of every successful project. The meetings 
required by award fee contracting reinforce 
the need for clear communication. 

Fourth, it has been my experience that con- 
tractor performance on award fee contracts is 
superior to performance by the same contrac- 
tors on other types of contracts. The quality 
of the product is certainly superior. The fee 
earned by those contractors is better than 
they could have received on other cost type 
contracts, and it should be. Remember: bet- 
ter performance, which the government 
wants, results in higher fees, which the con- 
tractor wants. I don’t have any data on fixed 
price contracts because there is no govern- 
ment knowledge of final costs of those types of 
contracts. But I’ll bet award fees are close to 
the profits customarily realized by contrac- 
tors, even on fixed price development con- 
tracts. 

The downside to award fee contracting is the 
additional contractor and government per- 
sonnel required to implement award fee con- 
tracts. It is certainly true that more people 
are needed to formally assess contractor per- 
formance, conduct performance evaluation 
board meetings, and report findings to the fee 
determination official. But I maintain that 
most of that work should be done under any 
circumstances, and the improved communica- 
tion is worth the effort. So I’m not sympa- 
thetic to those complaints. 



All the good features discussed above can go 
down the drain with faulty implementation. 
I’ve found the following nine ground rules to 
be effective in properly implementing the 


award fee contracts in which I’ve been in- 
volved. I will readily admit that there should 
be many ways to skin this cat, but frankly, 
I’ve found no effective alternatives to the fol- 
lowing rules. I’ve also seen instances where 
both the government and the contractor 
failed to reach their objectives as a direct re- 
sult of deviations from one or more of the fol- 
lowing rules. 

First, the government project manager 
must chair the Performance Evaluation 
Board (PEB). After all, the project manager 
is the key official selected by NASA to be re- 
sponsible for the project cost, schedule, and 
technical performance. The project manager 
is therefore in the best position to evaluate 
and judge the importance of the performance 
during the project evolution and obviously 
has the most to gain or lose from that perfor- 
mance or lack thereof. If that’s not true, the 
agency should find another project manager. 
On the other hand, it’s crucial that the con- 
tractor understand that the government pro- 
ject manager is the most influential govern- 
ment individual for all project activities, and 
looking elsewhere for project-level influence 
is unproductive. 

Second, the PEB should consist of institu- 
tional members who are participating in 
the project: procurement, business (pro- 
gram control in some Centers), engineering, 
and product assurance (quality control and 
safety at some Centers). Depending on the 
end item or service, science and operations 
should also be added. It’s advisable to keep 
the PEB membership as small as possible, 
and it’s important to select individuals with 
experience applicable to the end item or ser- 
vice delivered. In other words, make sure 
they are capable of understanding what the 
contract monitors are telling them. 

Third, the Fee Determination Official 
(FDO) should be no higher than one level 
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above the project manager and, in fact, 
should be the project manager’s line supervi- 
sor. The FDO must have more than a passing 
knowledge of the project’s status. This re- 
quires frequent interactions with the project 
manager, which the supervisor’s position pro- 
vides. Deviations from this rule can result in 
some awfully dumb fee determinations. I 
might add that if the project manager reports 
to the Center director, the deputy Center di- 
rector should be the FDO. Center directors 
should not be FDOs and should be reserved to 
resolve institutional or project issues should 
they arise. 

Fourth, use adjectives that can be under- 
stood and that properly describe perfor- 
mance levels. I prefer the academic model 
where "Satisfactory” is used for barely pass- 
ing performance (a 60 or 70 percent perfor- 
mance rating, depending on your preferences.) 
Levels below "Satisfactory” can be identified 
as "Poor” and "Failing.” Levels above "Satis- 
factory” can be called "Good” and "Excellent.” 
It’s confusing to everyone when fee curves are 
set so that the fee letter indicates a contractor 
got a "Superior” rating but received only 65 
percent of the available fee for that period. 
Don’t laugh; that’s actually happened. 

Fifth, skew the fee curve (fee earned vs. 
performance rating) so that most of the 
available fee falls above "Satisfactory,” or 
whatever you’ve decided to call passing per- 
formance. This clearly shows our desire for 
high performance and motivates the contrac- 
tor to exceed a mere passing grade. 

Sixth, make the award fee periods suffi- 
ciently long to allow time to correct defi- 
ciencies after a mid-term review by the 
project managers. I prefer six-month periods. 
This allows the project managers to assess the 
performance status three months into the pe- 
riod in order to identify performance prob- 
lems, and then still provides three months to 
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correct the situation before final evaluation 
and scoring of that period’s performance. 
Periods of less than four months preclude this 
important process. 

Seventh, offer contractors an opportunity 
to present self-assessments of their per- 
formance to the PEB and the FDO. Some 
contractors will choose not to do this, but the 
invitation ought to be given. If the offer is ac- 
cepted, I believe the PEB should hear the con- 
tractor’s self-assessment before making the fi- 
nal rating. As an FDO, I definitely preferred 
hearing the contractor’s self-assessment be- 
fore hearing the PEB’s story. Frankly, I’ve 
found that the major advantage of contractor 
self-assessments is that they indicate faulty 
government-contractor communication — 
which will kill a successful project more 
quickly than anything I know. 

Eighth, rollovers should be allowed in the 
award fee plan but never promised. They 
should be left to the discretion of the FDO and 
result from recommendations by the PEB. 
They should be used infrequently and always 
targeted to specific events that have become 
crucial to the success of the project. Specific 
"go/no-go” performance criteria must be es- 
tablished for these events and announced in 
the fee letter for the period preceding the peri- 
od in which the selected event falls. 

Finally — and most importantly — the 
contractor project manager and the gov- 
ernment project manager must jointly 
agree on milestones and criteria, and the 
emphasis to be placed on each, before the 
beginning of each award fee period. And 
then everyone must stick to the agreements . 
This won’t eliminate disagreements with the 
amount of fee awarded, but it does eliminate 
surprises, which are simply unacceptable. 
Nothing can kill an award fee process quicker 
— and demoralize contractors more — than to 
be "dinged” for something they didn’t know. 
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Wm Fee Determinations 

Now let’s look at the lessons learned in the 
awards themselves. The first and most impor- 
tant ground rule is: don’t play games . If the 
contractor earned all of the fee, by all means 
award it. Don’t fall into the trap of telling 
yourself, "If I give 100 percent, the contractor 
will start expecting it every time.” Or: "The 
contractor earned 100 percent, but I’ll give 80 
percent to give some room to improve.” Or 
just as bad: "If I give the contractor the 20 
percent really earned, I’ll get the project man- 
ager fired.” Awards that are too high or too 
low are equally bad. Awards that are too high 
tell the contractor to underperform and get 
away with it. Awards that are too low tell the 
contractor that no matter how hard the work 
and how much the accomplishment, efforts 
will be in vain. Both situations are bad and 
will demoralize the contractor. Stick to the 
prior agreements and award the fee consistent 
with the actual performance. If the perfor- 
mance is deficient and your awards are consis- 
tently fair, you’ll soon see the performance im- 
prove. If the performance is good, and the con- 
tractor is convinced that fees will be lost by 
backsliding, the performance will remain 
high. In case you didn’t notice, the operating 
word is fair . By the way, it’s a good idea to 
keep histograms for the percentage fee earned 
as the program develops. If the awards have 
been consistent (fair), you’ll see the hills (good 
times) and valleys (problems) that occur in 
any development activity. 

ff§|| Award Fee Letter 

Now for the important fee letter where you 
tell the contractor about the determination. 
Believe me, you can ruin a good award fee pro- 
cess and all the work you’ve done by issuing 
an award fee letter that no one understands. 
It would be impossible to overstate the impor- 
tance of these letters. I’ve found the letters 
should have four basic parts. The first para- 


graph is really a boilerplate paragraph that 
references the contract title and number, 
identifies the period for which the award is 
given, states the percentage of the award 
earned and the specific dollar amount, and 
gives the performance adjective rating. The 
second paragraph should identify the in- 
stances of commendable performance. Be spe- 
cific, even if you have to use bulleted items. 
Be clear. The contractor must understand 
which ratings were high so as to pass the acco- 
lades along to the working troops. The third 
paragraph should identify deficiencies. 
Again, it’s extremely important to be specific 
and clear. I call the final fourth paragraph 
the "message” paragraph. The content of this 
paragraph can range from "keep up the good 
work” to "be advised that continued inferior 
performance in (a certain area) will have seri- 
ous effects on future overall fee determina- 
tions.” 

A good contractor general manager will do 
several things with the fee letter — that is, if 
it is understood. First, a meeting with the 
project manager will be held to review the let- 
ter. The project manager will be commended 
for the things done properly (second para- 
graph), actions will be identified to correct re- 
currence of the deficiencies (third paragraph), 
and the message (fourth paragraph) will be 
discussed and actions (project or institutional) 
will be identified to respond to the thrust of 
the message. Next, the good general manager 
will send a letter to the FDO stating that the 
award has been reviewed with the project 
manager, the recognition of the commendable 
items is appreciated, the deficiencies and mes- 
sage are understood, and appropriate actions 
have been assigned. In addition, the general 
manager will now be in a good position to re- 
port the profit status on this contract and ar- 
ticulate the details of the award. All of these 
good things transpire when the contractor un- 
derstands the fee letter. Otherwise, there is 
no followup or feedback, the situation cannot 
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be explained to corporate reviewers, and ev- 
erybody loses. 

The understanding of the awarded fee is so 
important that I added one more step to the 
process. As an FDO, if a general manager 
called and verbally complained about certain 
elements of the award, I would discuss the call 
with the government project manager and 
provide verbal feedback to the general man- 
ager. If the complaint came in writing, I 
would reconvene the PEB with instructions to 
draft a written response to only the specific 
concerns stated in the general manager’s let- 
ter, not every element of the award. I would 
then discuss the recommended government 
response with the PEB. If I agreed with the 
PEB position, I would send the written re- 
sponse to the general manager. By the way, I 


have changed a prior award in the contractor’s 
favor after learning that the PEB used errone- 
ous information. In that case, the general 
manager was correct and the contractor 
earned the fee increase. After all, that was 
the fair thing to do. The contractor response 
to that small dollar change was tremendous, 
and performance improved markedly. 

So in summation, I believe that award fee con- 
tracting is particularly suited to the one-of-a- 
kind development projects which constitute 
most of NASA’s efforts. I do not believe fixed 
price contracts or fixed price plus incentive 
contracts belong in this environment. Per- 
haps someone else may wish to argue the ad- 
vantages of the latter types, but my exper- 
ience suggests that award fee contracting is 
the better way to go. 
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COBE's three instruments will be able to observe , map and measure the entire sky twice during its 1 year mission 
lifetime. COBE, which includes the FIRAS instrument , is 19 ft (6 m) long and 29 ft (9 m) in diameter once the ar- 
rays are extended. The instruments measure radiation from a variety of objects in space and the cosmic back- 
ground radiation of the " Big Bang ” 
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COBE: Lessons Learned from the Management of FIRAS 

by Mike Roberto 


On November 18, 1989, NASA launched the 
COsmic Background Explorer (COBE) from 
Vandenburg Air Force Base in California. 
COBE’s mission is to orbit 559 miles above the 
Earth for one year to study the origin and dy- 
namics of the universe by measuring diffuse 
infrared radiation and microwaves, including 
the cosmic background. COBE will also test 
the "Big Bang” theory of the origin of the uni- 
verse, predicated 15 billion years ago. 

COBE is carrying three principal instruments 
to map the sky at 100 microwave and infrared 
wavelengths. The Differential Microwave Ra- 
diometer (DMR) is looking to see whether the 
original explosion was equally bright in all di- 
rections, or whether patchy brightness will 
unveil the origins of galaxies, clusters of gal- 
axies, and clusters of clusters of galaxies. The 
Diffuse Infrared Background Experiment 
(DIRBE) is searching for the light of the oldest 
stars and galaxies by measuring the collective 
glow of millions of objects, accounting for all 
known sources of emissions, and seeing what 
signals remain. The third instrument is the 
Far Infrared Absolute Spectrophotometer 
(FIRAS), which measures the spectrum of the 
cosmic background radiation from the "Big 
Bang” and intergalactic dust. A smooth black 
body spectrum with small deviations is pre- 
dicted. Any deviation may indicate other 
powerful energetic events from the period of 
universal history shortly after the "Big 
Bang,” such as annihilation of antimatter, 
matter swallowed by black holes, or super- 
massive exploding objects. 

FIRAS was designed, built, and integrated at 
NASA Goddard Space Flight Center. The en- 


tire process was kept in-house, the first time 
such a complex project had been done this 
way. While the outcome was successful, the 
process did not always go smoothly. Follow- 
ing are some of the lessons learned from this 
experience. 

1. Matrix management 

Problem: Four divisions and numerous 

branches of Goddard’s Engineering Director- 
ate provided excellent support to FIRAS. 
However, the support personnel had other 
concurrent responsibilities and were not un- 
der the direct control of the FIRAS manage- 
ment team. Because they were not always 
available, more flexibility was needed in the 
schedule. 

Solution : With limited personnel resources, 
there is no easy solution here. There is a 
trade-off between keeping support personnel 
in their organizations where they can inter- 
face with peers on technical problems and co- 
locating a team to support the instrument. 

2. Breadboarding vs. system modeling 

Problem: Too much time was spent develop- 
ing breadboard subsystems, making the proj- 
ect too much like experimental research. A 
lot of time was spent varying parameters to 
arrive at the right recipe for the operation of 
temperature controllers. 

Solution: Have good analytical capability for 
modeling from the beginning. Then you can 
run computer simulations, changing param- 
eters and predicting results. Use system 
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modeling extensively in the beginning of the 
process, before breadboarding. During most of 
FIRAS integration and testing, we did not 
have an analysis program to predict the prop- 
er temperature controller settings. After the 
analytical model was developed, establishing 
settings became routine and quick. 

3. Peer level design reviews 

Problem-. The design reviews were not de- 
tailed enough to catch subtle design problems. 
For example, the mirror transport mecha- 
nism (MTM) was a good mechanical design 
but complex enough that proper assembly was 
not immediately apparent. If the assembly 
were not perfect, the mechanism would not 
work properly. Parts were assembled at ambi- 
ent temperature and cooled to near absolute 
zero; components cool at different rates and to 
different lengths. 

Solution : Have experts perform a thorough 
technology assessment early in the program. 
Then you can find out early which parts of the 
program need more emphasis and more work; 
you can point out potential problem areas 
which are technology drivers. Reviews should 
be held at each level of maturity of design, so 
that problems can be caught early, before the 
hardware is cut. Peer reviews should be con- 
ducted in small groups in a small conference 
room where the diagrams can be put on a con- 
ference table for people to review together. 
The reviewers are thus more likely to discuss 
the diagrams and to mark problem spots and 
indicate solutions. When the review is held in 
a large conference room with a large group 
and the diagrams projected on a screen, the at- 
mosphere is less conducive to criticism, dis- 
cussion, and changes. 

4. Comprehensive system level approach 
to system design 

Problem : The responsibility for the various 
electronic subsystems of FIRAS was divided 


among different branches and divisions. 
Some FIRAS circuits required modification 
late in the program. For example, the MTM is 
extremely complex. We didn’t find out how 
noisy it was until it was installed on the 
spacecraft; we then had to modify the elec- 
tronics design of the shielding and grounding 
to make it work properly. This including pig- 
gybacking a box onto the drive electronics box 
to eliminate noise and to ensure that the 
MTM would recover from any scan upsets. 
Before modification the mechanism would oc- 
casionally go to the end of its course for a 
while, where it drew excessive power. Once 
the problems were corrected, it performed 
flawlessly. 

Solution: Early in the evolution of the elec- 
tronic system design, the instrument team 
needs to have an expert on grounding, noise 
immunity, electronics components and inter- 
faces, etc., to coordinate the overall system de- 
sign. This skilled individual should have 
overall responsibility for all the electronics. 

5. Engineering model 

Problem : The engineering model was deleted 
from the program because of time and cost. 
An engineering model could provide some 
flight spare components as well as an instru- 
ment for testing fixes on the ground before 
trying to correct an on-orbit problem. The 
FIRAS team ended up making changes to 
flight hardware. 

Solution: There is no easy solution here. An 
engineering model of FIRAS would have been 
more expensive and time-consuming than the 
modifications made to the flight hardware. 
However, for an instrument as complex as 
FIRAS, I believe an engineering model would 
have been good insurance. 

6. Documentation 

Problem: With the pressing schedule, the 
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FIRAS team received hardware without its 
documentation. The same people who sup- 
plied the hardware had to prepare the docu- 
mentation. To maintain the schedule, testing 
had to proceed without all supporting docu- 
mentation. 

Solution : Insist that without complete docu- 
mentation, the hardware is not considered to 
be delivered. 

7. Test requirements and schedule 

Problem: In the FIRAS test program, tests 
were sometimes shortened or deferred to a 
higher level of integration to maintain the 
schedule. FIRAS paid a price for trying to 
maintain the schedule. The problem of the 
Xcal (external calibrator) not staying in the 
horn was not discovered until FIRAS was in 
the flight dewar. The MTM drive electronics 
required modification on the spacecraft, and 
then a special electronics box had to be moun- 
ted on the drive box (see #4). The lesson here 
is that the risks of a success-oriented schedule 
are very real. 

Solution : There is no easy solution here ei- 
ther. We’re doing Monday morning quarter- 
backing. The success-oriented schedule had 
many successes, but going back into the dewar 
was a big hit (costing us more time in the long 
run). At times, a more flexible schedule would 
have helped. 

The FIRAS team could have fought harder for 
additional time at certain critical points in the 
program. 

8. Software support 

Problem: FIRAS was severely constrained by- 
having to use the developing mission software 
system for its instrument integration and 
testing. The software was periodically modi- 
fied as it was being developed as a ground sup- 


port system for the mission. The integration 
and test team had to use the same software; 
when the version of the VAX operating sys- 
tem was changed right before a test, the soft- 
ware would not work properly for the integra- 
tion and test team. The integration and test 
effort was necessary for launch, but the team 
felt they were being used as guinea pigs for 
the new software, rather than having soft- 
ware developed to support their efforts. They 
had no control; they couldn’t prevent the soft- 
ware from being modified as they were pre- 
paring to conduct a test. 

Solution: Instrument integration and testing 
needs independent, dedicated software sup- 
port. 

9. Programmed pauses 

Problem: A number of times in the FIRAS 
program, the FIRAS team fell behind sched- 
ule. We were trying to prepare for the next 
item on the schedule while also bringing test 
procedures, test reports, etc., up to date. We 
would get into a new test without having a 
chance to completely evaluate the results of 
the previous test. It was easier at times to run 
a test again, rather than to go back and try to 
process old data. 

Solution: At times in a test program, it may 
be necessary to stop everything and get up to 
date. This may save time in the long run. 

10. Common language 

Problem: We tested FIRAS using one version 
of STOL, a program for commanding the in- 
strument from a computer. The spacecraft 
has a slightly different version of STOL. The 
POCC (payload operations control center) has 
a significantly different version of STOL. 

Solution: Use the same test language from 
the start. 


31 



COBE: Lessons Learned from the Management of FIRAS 


11. Procedure changes 

Problem : It was a rare event for a FIRAS test 
procedure not to go through several iter- 
ations.We made considerable extra work for 
ourselves in developing and reviewing new 
procedures for early orbit operations and the 
FIRAS mission. 

Solution: Develop procedures from the start 
with inputs to cover all phases of the program. 
This would require a lot of coordination in the 
beginning, with procedures reviewed by sub- 
system, engineering, science, and operations 
personnel. However, the overall program 
would be more efficient and more appropriate. 

12. Personnel work hours 

Problem: The COBE work has been exciting 
and demanding. However, a work schedule 
that runs through holidays, nights, and week- 
ends for extended periods is usually not good 
for the individual. Health and efficiency may 
be affected. There should be a way to main- 
tain a steady work pace that allows the indi- 
vidual to keep up with responsibilities outside 
of work. 

Solution: There is no easy solution here. 
Mandatory time off would mean that the proj- 
ect would take longer and be more expensive. 
At Goddard, projects are where the action is. 
One could say that if you can’t stand the heat, 
get out of the kitchen. Some people want to 


work lots of extra hours. However, since this 
is now a "kinder and gentler nation,” project 
work could be made available for individuals 
content with working more normal work 
weeks. 

||| Conclusions 


People at Goddard received a lot of training 
with the COBE project. Goddard benefitted as 
a whole; it learned that it could handle a large 
project in-house. 

The FIRAS team was to a large extent captive 
to the overall push to complete COBE. COBE 
put an extraordinary demand on personnel, 
money, and facility resources. Better plan- 
ning might have allowed for more efficient re- 
source utilization. As the magnitude of the 
job became evident, it would have been help- 
ful to conserve personnel resources by reduc- 
ing night, weekend, and holiday work. Addi- 
tional facility (and money) resources would 
have been required, but there would have 
been a better overall balance in resource utili- 
zation. 

In the end, everything came together. We are 
very excited about how well FIRAS and the 
other instruments are working. It is hard to 
argue with success. Thus COBE may rein- 
force our dependence on extraordinary person- 
al efforts by our people. Any volunteers for 
COBE 2? 
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Management of Small Projects: 
Streetfighting in the NASA System 

by William J. Huffstetler 


The NASA management system, as it has 
evolved over the past three decades, is charac- 
terized by larger projects. Ambitious plans, 
bold directives, massive budgets, and tens of 
thousands of workers characterize the most 
spectacular achievements of NASA, yet all 
during the huge Apollo and Shuttle programs, 
NASA was involved in hundreds of smaller 
projects, some of them totally unrelated to 
their much bigger contemporaries, serving 
the needs and aspirations of American and in- 
ternational science and technology. 

NASA counts some 20,000 "spinoffs” or 
technologies twice used, about half of them 
related to medical science. Many of these 
spinoffs are the direct result of NASA’s 
smaller projects. NASA is one agency whose 
parts are greater than the whole, whose sum 
yield is higher than the total of projects. 

What is a "small project” at NASA? It is de- 
fined as any project not supported by a large 
pipeline of dollars from a major program or 
project. It can be a minuscule, stand-alone 
part of a major program, but it usually has a 
short life cycle, perhaps 18 to 36 months. 
While it may have a lower priority in a NASA 
Center’s goals or objectives, a small project is 
not considered extra, optional, or expendable 
— it is considered a mandatory activity. 

Murphy’s Laws enable us to understand the 
real beauty of a small NASA project. The 
shorter life cycle of a small project goes a long 
way in protecting us from Murphy’s Four- 
teenth Law: If you fool around with a thing 
for very long, you will really screw it up. Most 


of all, a small NASA project provides two im- 
measurable benefits not ordinarily found in 
mega-projects: considerable "hands-on,” in- 
house activities, and a marvelous opportunity 
to have some fun. But to manage a small 
project at NASA you need to know something 
about the art of streetfighting. 


Ill Like a Real Business 


Managing small projects is the closest thing to 
running a true business you can find inside 
NASA, or within the government for that 
matter. Small businesses have to streetfight 
and most new businesses are knocked out in 
two years or less. Streetfighting techniques 
can be applied to small government projects as 
well. 

First of all, the first decision for a private 
business is selection of a product line. NASA 
does this every day, examining the needs of 
the nation and the projects to meet various 
conflicting and shifting priorities, to the satis- 
faction of Center goals. 

Next comes evaluation of competition. True 
businesses merely have to study other produc- 
ers in order to begin planning and market 
strategy, but competition within NASA can 
come from many sources. Some are internal 
(such as other funded projects), and some are 
external (such as user needs). As the new 
NASA manager on the block begins to street- 
fight for a project he or she believes in, things 
get rough. As Murphy notes, friends come and 
go, but enemies accumulate. 


33 


Management of Small Projects: Streetfighting in the NASA System 


romm 


The common next step for private enterprise 
is conceptualizing, a process that involves 
both strategy and credibility. In planning, 
you don’t want to eliminate any idea or con- 
cept initially — but then, you do not want to 
plan by committee, either. Near-term action 
(two to four years) is easy, but long-term 
strategy (four to eight years) will require 
phases for major decision points. The idea is 
to gain credibility for the project by breaking 
new ground — in small pieces, not big 
chunks. 

The business world next considers risk as- 
sessment. For managers of small projects, 
technical and programmatic risks should be 
distinguished. I would assume minimum risk 
technically and maximum risk programmati- 
cally. The turtle moves forward only when its 
neck is sticking out from its protective shell. 

Marketing comes next in small business: 
selling and convincing people of the concept. 
For small projects, that means internal sell- 
ing. Establish a visible "golden cookie” for all 
those from whom you need support. What’s in 
your project for them? How are the organiza- 
tion’s aims and aspirations reflected in this 
small project? Market yourself as a leader — 
managers are a dime a dozen, but leaders are 
worth millions. Convince others that you can 
handle the project, but remember that major 
conflicts will come from within. 

So a continuing process of reinforcement is re- 
quired to sustain commitments. Murphy 
warns, however, that if you try to please ev- 
erybody, nobody will like it. Commit yourself 
to the project, and convince others. Lead, 
don’t follow, in the marketing of your small 
project. 

Can you deliver the small project on time, on 
budget, with the people assigned to you? To 
be sure, take a chapter from the business 
book and do some "resource projections.” 


Think twice about assurances of success until 
you have the people, dollars, and schedule. 

You may be asked to do a "cost-to-benefit” 
study, as commonly practiced in thebusiness 
world. While some people claim that if gov- 
ernment were a business, it would go out of 
business, others would say that government is 
there to take risks in order to push technology 
and expand the frontiers of science. Even if 
the numbers look bad, lead — don’t follow the 
numbers. Use the numbers, don’t be used by 
them, for strong leadership is mandatory on 
small projects. 



Acquisition and Implementation 


So you sold the project. Now what do you do? 
Acquisition and implementation is the cus- 
tomary final phase of a typical business plan 
outlined above, but I want to spend some time 
on this. Most people would think you put all 
your energy into design, development, test, 
and certification. That’s the easy part of the 
project. 

The hardest part is requirements. 

Developing strong yet flexible requirements 
can make or break a small project. While it is 
estimated that one hour of planning can save 
perhaps three or four hours of execution, Mur- 
phy adds that anything you try to fix will take 
longer and cost more than you could imagine. 
Changes occur at the blink of an eye. They 
may come from any direction, friend or foe. 
But the major syndrome, costing valuable 
time and money, is: "I forgot.” 

The key to successful acquisition is control, 
but such control must be self-imposed, and, 
more important, self-maintained. Let George 
do it, and George should have your job. Throw 
out your plans and strategy, and here comes 
trouble. 
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Throughout the implementation of a small 
project (and most large ones as well), the man- 
ager discovers the necessity of a continuing 
process in justifying the project’s existence. 
Here come budget cuts. Can we still proceed? 

Here come new priorities. Can we adapt to 
them? And where did all the project’s advo- 
cates go? You left it to George, and George 
left. 

At this point you had better control the risks, 
for, as Murphy observed, the light at the end 
of the tunnel is actually the headlamp of an 
oncoming train. 

There is no such thing as an optimum organi- 
zation. There are only good leaders. And then 
there are managers. Anyone can manage, but 
few can really lead. 

In practical terms for small projects, this 
means giving maximum authority to project 
engineering and project managers. It starts 
with honesty: you do not and cannot know ev- 
erything about everything. Develop close re- 
lationships with subordinates in a spirit of 
honesty and trust. Be flexible and adjustable, 
reducing tensions as much as possible. Above 
all, develop leaders, not merely more manag- 
ers. 

An organization is strengthened when it be- 
comes an organism, when your team numbers 
know and feel personally responsible for their 
work. Authority is delegated to the lowest 
possible level, and commitment to the project 
rises to the maximum. 

Some managers are continually on the look- 
out for project visibility. If it’s visibility you 
want, have a failure while all else on the 
flight is nominal. Maximum visibility, how- 
ever, does not necessarily result from a totally 
successful flight project; rather, it is provided 
by project products that fly. 


Visibility in an organization is a tricky con- 
cept. Support for projects will appear to be to- 
tally nil — or you will be helped to death. 
Visibility is not always desirable for an orga- 
nization. A genuine leader will recognize oth- 
ers on the team but will not seek personal rec- 
ognition. 

mWM 

111 ! So, Why Manage Small Projects? 

You want to manage small projects because 
the rewards are so great. 

On a small project, rewards are more personal 
than tangible. Success is sweeter for some- 
thing over which you have major (though nev- 
er total) control. And the personal relation- 
ships, good and bad, built up over the lifetime 
of a small project will stay with you for the 
rest of your life. 

Those relationships are based upon building 
leadership through responsibility and author- 
ity delegation. The small project is the per- 
fect mechanism for educating younger per- 
sonnel by integrating them with oldtimers. 

With the Apollo-era engineers and techni- 
cians retiring at an alarming rate, their wis- 
dom finds no better place to live on than in 
the hearts and minds of those working so 
closely together on a small project. 

One venerable oldtimer, now officially re- 
tired, is Clarence L. "Kelly” Johnson who cre- 
ated his famous "Skunk Works” at Lockheed 
in 1943. 

The "Kelly Johnson factor” is a true educa- 
tional experience in both learning and teach- 
ing, perfectly suited to the management of 
small projects. Kelly proved that projects led 
by small committed project teams could be 
fun as well as challenging, and some of his 
precepts are paraphrased and outlined on the 
next page. 
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Basically, Kelly Johnson pulled a few good 
people together, gave them authority from be- 
ginning to end, and let them tackle tough 
problems with the simplest of tools and meth- 
ods. In a mere 43 days, ten dozen people, in 
eluding 23 engineers, built the first U.S. fight- 


er plane to fly faster than 500 mph. With un- 
expected shared authority, this team focused 
on a single, clear objective and had enormous 
fun achieving it. Managers of small projects 
at NASA would do well to reflect upon what 
Kelly Johnson learned and taught. 


Kelly Johnson’s 

SKUNK WORKS: BASIC OPERATING RULES 

1. The manager delegates practically complete control of the program in all aspects; re- 
ports go to highest level. 

2. The projects office is small, but strong . 

3. The number of people having any connection with the project is restricted in an "almost 
vicious manner.” 

4. The drawing and drawing release systems are very simple, with great flexibility in mak- 
ing changes. 

5. Required reports are at a minimum, but important work must be recorded. 

6. Monthly cost reviews cover what has been spent and committed, and projected costs to 
completion, 

7. The contractor must be delegated and must assume more than normal responsibility for 
good bids on subcontract project work. 

8. Existing inspection systems are used, with more basic inspection sent back to subcon- 
tractors and vendors. Don’t duplicate. 

9. The contractor delegates authority to test the final product in flight. 

10. Specs applying to hardware must be agreed to in advance of contracting. 

11. Funding must be timely. 

12. Mutual trust is sustained between project organization and the contractor. Closest coop- 
eration is on a day-to-day basis. 

13. Access to the project by outsiders is strictly controlled. 

14. Ways must be provided to reward good performance. 

— See Chapter 16, "It’s No Secret,” of Clarence L. "Kelly” Johnson’s Kelly: More Than 
My Share of It All (Washington, D.C.: Smithsonian Press, 1985), reviewed in Issues in 
NASA Program and Project Management , NASA SP-6101(02). 
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by Michael L. Ciancone 


The loss of technical expertise through attri- 
tion in the technical work force is a growing 
concern throughout NASA and the aerospace 
industry, and may impact on the way NASA 
manages projects. An unusual distribution of 
age groups among scientists and engineers 
(S&Es) within NASA presents both chal- 
lenges and opportunities to NASA managers. 

This article documents historical age-related 
S&E information within NASA in general, 
and the NASA Lewis Research Center 
(LeRC), Cleveland, Ohio, in particular, for 
1968 through 1988, and discusses the implica- 
tions for NASA managers. Recommendations 
are made for addressing the age distribution 
issue to provide a practical approach for avoid- 
ing adverse consequences and for allowing us 
to take advantage of opportunities that may 
arise. 

The reputation of any technical organization 
is based on the individuals who comprise its 
work force, including both supervisory and 
nonsupervisory S&Es. These individuals 
form the core of the organization’s technical 
and programmatic memory. It is essential to 
the viability of these organizations that they 
maintain a critical core of experienced indi- 
viduals. Equally important is the need to at- 
tract, develop, and retain individuals who will 
comprise the agency work force in the years to 
come. This is the challenge of balancing 
short-term needs (i.e., utilizing existing ex- 
perience to meet current demands) and long- 
term needs (i.e., developing new talent to 
meet projected demands). 


Early in the U.S. civilian space program, fol- 
lowing the formation of NASA in 1958, many 
S&Es were hired directly out of college by 
NASA, supplementing those who made the 
transition from the former NACA and those 
who were drawn from military programs. 
These young S&Es acquired invaluable exper- 
ience as they matured along with NASA 
through the U.S. civilian manned space pro- 
grams, including the Mercury, Gemini, and 
Apollo programs. 

In the late 1960s, forces external to NASA 
(e.g., congressional and administration priori- 
ties, and budget constraints) dictated a de- 
crease in the size of the NASA workforce (and 
a corresponding decrease in the number of 
S&Es) as the Apollo program drew to a prema- 
ture close. 1 More recently, an influx of new 
hires in the early 1980s has helped to bolster 
the NASA S&E base in support of a revital- 
ized mission, including programs such as 
Space Station Freedom. As a result, we are 
faced with a combination of a large number of 
S&Es nearing retirement age, a shortage of 
mid-career S&Es, and a large cadre of rela- 
tively inexperienced S&Es. Aggravating the 
situation is an anticipated downturn in the 
number of S&E graduates who will be avail- 
able to the agency in the coming years. 

If we assume that the S&Es hired in 1958 
were recent college graduates with an average 
age of 22, then these employees will be eligi- 
ble to retire under the existing Civil Service 
Retirement System (CSRS) in 1991, i.e., with 
at least 30 years of service and at 55 years of 
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age. Current personnel statistics reflect an 
average retirement age among NASA S&Es of 
60. 2 The impact produced by the introduction 
of the Federal Employee Retirement System 
(FERS), supplanting the "golden handcuffs” of 
the CSRS, have yet to be fully determined. 

The following information was obtained from 
raw data and annual work force summary re- 
ports prepared by the NASA Personnel Evalu- 
ation and Analysis Division for the years 1968 
through 1988 to determine our current situa- 
tion in light of relevant historical trends. 
NASA S&Es are defined by the following posi- 
tion categories: support engineering and re- 
lated positions, aerospace technology (AST) 
S&E positions, and life science positions. 

Support engineering and related positions in- 
clude professional physical science, engineer- 
ing, and mathematics positions in work situa- 
tions not identified with aerospace technol- 
ogy. AST S&E positions include professional 
scientific and engineering positions requiring 
AST qualifications, and professional positions 
engaged in aerospace research, development, 
operations, and related work including the de- 
velopment and operation of specialized facili- 


Total 



Years 

Figure 1. - NASA Civil Service Workforce 


ties, and supporting engineering. Life science 
positions include life science professional posi- 
tions not requiring AST qualifications, and 
medical officers and other positions perform- 
ing professional work in psychology, the bio- 
logical sciences, and professions that support 
the science of medicine such as nursing and 
medical technology. 

Figure 1 shows the general trend in both the 
total number of NASA civil service workers 
(CSs) and the number of CS S&Es. However, 
Table 1 indicates that, throughout the vari- 
ations in the size of the NASA CS workforce, 
the percentage of S&Es in the total NASA CS 
workforce increased — from 36.5 percent in 
1963 to 54 percent in 1988. This increase was 
not unexpected as many former CS, non- S&E 


YEAR 

TOTAL 

S&Es 

S & Es as 
a percent 
of total 

1963 

28,358 

10,340 

36.5 

1964 

31,285 

11,893 

38.0 

1965 

32,697 

12,838 

39.3 

1966 

33,538 

13,282 

39.6 

1968 

33,677 

13,681 

40.6 

1968 

32,471 

13,851 

42.7 

1969 

31,733 

13,839 

43.6 

1970 

31,223 

13,837 

44.6 

1971 

29,478 

13,227 

44.9 

1972 

27,428 

12,616 

46.0 

1973 

25,955 

12,085 

46.6 

1974 

24,854 

11,770 

47.4 

1975 

24,333 

11,665 

47.9 

1976 

24,039 

11,612 

48.3 

1977 

23,569 

11,544 

49.0 

1978 

23,169 

11,465 

49.5 

1979 

22.633 

11,291 

49.9 

1980 

21,613 

11,200 

49.5 

1981 

21,844 

10,923 

50.0 

1982 

21,186 

10,746 

50.7 

1983 

21,505 

11,094 

51.6 

1984 

21,050 

10,879 

51.7 

1985 

21,423 

11,144 

52.0 

1986 

21,228 

11,147 

52.5 

1987 

21,831 

11,679 

53.5 

1988 

21,991 

11,866 

54.0 


Table 1. - NASA Civil Service Workforce 
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positions were converted to positions involv- 
ing activities that could be provided by pri- 
vate industry. Although these mandated con- 
versions contributed to the depletion of in- 
house talent, a conscious effort was made by 
NASA management to retain the technical 
expertise of the S&E workforce as much as 
possible. 

Figure 2 illustrates the changing age distribu- 
tion among NASA S&Es, at 10-year intervals. 
Table 2 tabulates the NASA S&E age data for 
1968 through 1988. NASA has gone from a 
"young” agency in 1968 during the height of 
Apollo, to a somewhat normal age distribution 
in 1978, to the current bimodal age distribu- 
tion. 

A bimodal age distribution, i.e., with two dis- 
tinct peaks or modes, may preclude a smooth 
personnel transition as experienced senior 



AGE, YEARS 

Figure 2. - Age Distribution Among NASA 
Scientists and Engineers 

S&Es are succeeded by available personnel, 
consisting of a relatively few mid-career S&Es 
and relatively inexperienced S&Es. Since 
1968, 19 to 23 percent of the total S&E popu- 


YEAR 

AGE RANGE 

TOTAL 

<25 

25-29 

30-34 

35-39 

40-44 

45-49 

50-54 

55-59 

> 60 

1968 

633 

2,168 

2,945 

2,767 

2,136 

1,874 

815 

347 

166 

13,851 

1969 

459 

1,946 

2,849 

2,829 

2,150 

2,097 

900 

406 

203 

13,839 

1970 

381 

1,718 

2,658 

2,914 

2,235 

2,167 

1,085 

472 

207 

13,837 

1971 

286 

1,396 

2,435 

2,837 

2,243 

2,103 

1,248 

477 

202 

13,227 

1972 

135 

1,109 

2,185 

2,746 

2,383 

1,950 

1,452 

453 

203 

12,616 

1973 

89 

801 

2,000 

2,594 

2,517 

1,900 

1,559 

467 

158 

12,085 

1974 

108 

606 

1,769 

2,524 

2,541 

1,888 

1,684 

486 

164 

11,770 

1975 

153 

521 

1,537 

2,408 

2,608 

1,962 

1,701 

594 

181 

11,665 

1976 

186 

468 

1,308 

2,264 

2,662 

2,050 

1,738 

736 

200 

11,612 

1977 

167 

456 

1,063 

2,072 

2,574 

2,314 

1,685 

974 

239 

11,544 

1978 

176 

503 

874 

1,928 

2,528 

2,406 

1,683 

1,098 

269 

11,465 

1979 

199 

503 

728 

1,744 

2,475 

2,482 

1,671 

1,175 

314 

11,291 

1980 

349 

598 

725 

1,544 

2,379 

2,562 

1,733 

977 

333 


1981 

317 

666 

725 

1,343 

2,212 

2,551 

1,772 

952 

385 

10,923 

1982 

328 

710 

660 

1,159 

2,060 

2,475 

1,927 

966 

461 

10,746 

1983 

602 

809 

709 

958 

1,940 

2,454 

2,049 

1,034 

539 

1 1,094 

1984 

557 

909 

706 

842 

1,723 

2,379 

2,091 

1,074 

598 

10,879 

1985 

636 

1,168 

781 

837 

1,508 

2,269 

2,171 

1,137 

637 

11,144 

1986 

549 

1,375 

887 

862 

1,327 

2,120 

2,207 

1,183 

637 

11,147 

1987 

627 

1,612 

1,055 

916 

1,229 

2,044 

2,206 

1,307 

683 

11,679 

1988 

522 

1,755 

1,243 

993 

1,102 

1,960 

2,253 

1,328 

710 

11,866 


Table 2. - Number of NASA Scientists and Engineers 
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lation has consistently been concentrated in 
the peak age group. The percentage of S&Es 
between 30 and 50 years of age has steadily 
decreased since 1970, while the percentage of 
S&Es over 50 has steadily increased (al- 
though at a slightly lower rate of increase 
than the rate at, which the percentage be- 
tween 30 and 50 decreased). In addition, the 
decreasing trend in the percentage of S&Es 
under 30 was reversed about 1980. As of 
1988, 19 percent of NASA S&Es are under 30, 
and 36 percent are over 50. 

The NASA-LeRC data represents a microcosm 
of NASA’s S&E age distribution trends. Fig- 
ure 3 presents NASA-LeRC S&E data (tabu- 
lated in Table 3), comparable to the NASA 
S&E data presented in Figure 2. During this 
time period, NASA-LeRC S&Es constituted 
10 to 13 percent of NASA’s S&E work force. 



AGE RANGE. YEARS 

Figure 3. - Age Distribution Among NASA 
LeRC Scientists and Engineers 

Figure 4 illustrates that the average age of 
NASA’s S&Es increased at a rate of 0.65 
years/year between 1968 and 1978. NASA’s 


YEAR 

AGE RANGE 

TOTAL 

<25 

25-29 

30-34 

35-39 

40-44 

4549 

50-54 

55-59 

>.60 

1968 

56 

271 

340 

355 

301 

296 

118 

53 

22 

1,812 

1969 

35 

233 

321 

342 

294 

326 

138 

57 

32 

1,778 

a 1970 

27 

194 

312 

331 

302 

329 

170 

66 

28 

1,757 

1971 

19 

154 

302 

320 

309 

332 

202 

75 

23 

1,736 

1972 

12 

102 

271 

306 

308 

287 

238 

73 

31 

1,628 

1973 

6 

66 

223 

265 

300 

260 

249 

67 

22 

1,458 

1974 

5 

43 

188 

256 

286 

245 

245 

73 

22 

1,363 

1975 

6 

38 

153 

254 

271 

265 

242 

89 

25 

1,343 

1976 

18 

34 

111 

244 

270 

262 

250 

128 

31 

1,348 

1977 

25 

36 

90 

230 

260 

268 

240 

158 

32 

1,339 

1978 

28 

40 

64 

209 

253 

276 

228 

173 

43 

1,314 

1979 

29 

42 

58 

177 

247 

285 

220 

197 

47 

1,302 

1980 

27 

50 

57 

141 

251 

266 

244 

155 

47 

1,238 

1981 

19 

59 

52 

116 

240 

253 

226 

157 

61 

1,183 

1982 

33 

66 

49 

96 

226 

239 

212 

151 

72 

1,144 

1983 

133 

98 

80 

73 

213 

236 

227 

148 

88 

1,296 

1984 

122 

112 

79 

64 

180 

240 

233 

156 

91 

1,277 

1985 

114 

176 

87 

74 

146 

247 

226 

173 

94 

1,337 

1986 

46 

218 

92 

75 

122 

231 

230 

161 

104 

1,279 

1987 

56 

249 

127 

92 

108 

228 

229 

164 

120 

1,373 

1988 

32 

231 

174 

101 

90 

190 

242 

195 

137 

1,392 


Table 3. - Age Distribution Among NASA LeRC Scientists and Engineers 
a Figures for 1970 were obtained through interpolation of the data from 1969 and 1970 
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YEAR 

Figure 4. - Average Age of NASA 
Scientists and Engineers 


S&E aging trend, both at LeRC and through- 
out the agency, has stabilized since 1979, pri- 
marily as a result of the infusion of S&E new 
hires and the inevitable loss of senior S&Es. 



Recommendations 


The following list of recommendations ad- 
dresses several facets of a plan of action that 
will allow us to take advantage of opportuni- 
ties and successfully face challenges. It in- 
cludes measures that are extensions of or vari- 
ations on existing NASA initiatives and is in- 
tended to be as practical as possible to facili- 
tate implementation at the lowest possible or- 
ganizational level without necessitating ei- 
ther an act of Congress or an act of God. 



Hire Experienced S&Es 


Perhaps the most obvious course of action 
when faced with a low level of in-house exper- 
ience is to look outside the organization for 
available talent. However, it may not be fea- 
sible to replenish the pool of experienced per- 
sonnel by hiring from outside NASA if the bi- 
modal age distribution among NASA S&Es is 
indicative of the situation in the aerospace in- 
dustry in general. Discussions with S&Es in 


the private sector indicate that this seems to 
be the case. 

The size of the available S&E employment 
pool in the U.S. work force cannot be stated 
with certainty, but it has been reported that 
upwards of 50 percent of those earning B.S. 
degrees in S&E-related fields transfer out of 
the S&E field.3,4 This loss of available talent 
was perhaps most evident during the down- 
turn in aerospace industry employment dur- 
ing the 1970s. More recently, events in east- 
ern Europe have led to speculation that a re- 
duction in the funding of military programs 
will lead to the greater availability of exper- 
ienced S&Es from the military side of the 
aerospace industry. However, this merely re- 
presents an additional factor in an already un- 
certain equation. 

The availability of new S&Es is not expected 
to improve in the near future — forecasts are 
that there will be an increase in the demand 
for engineers through the 1990s, while the 
supply will be decreasing, primarily as a re- 
sult of the busted baby boom reducing the size 
of the traditional pool of students entering 
S&E fields. 5 . 6 The issue of attracting students 
to S&E fields, a "pipeline” issue, will not be 
addressed here. 

An additional source of experienced S&Es 
that should not be overlooked are recent re- 
tirees. These experienced retirees can be uti- 
lized through support service contractors or as 
private consultants when comparable, but un- 
available, S&Es are needed. The 1989 enact- 
ment of Public Law 100-679 (Post Employ- 
ment Restriction Act) placed restrictions on 
post-employment activities for former federal 
procurement officials and resulted in acceler- 
ating the retirement of some employees, but 
any long-term effect on retirement statistics is 
likely to be negligible. Further complicating 
this situation was the recent suspension of 
PL 100-679 by Congress until December 1, 
1990. 
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Although contentious, the use of retirees via 
support service contracts or as private consul- 
tants is particularly appealing when person- 
nel funding (R&PM) is limited, but contract- 
ing funds (R&D) are available. Such an effort, 
however, should not detract from the develop- 
ment of an in-house technical workforce. In 
essence, it only serves to postpone the inevita- 
ble transition of experience. 

Regardless of the success of our efforts to hire 
experienced S&Es from outside NASA, we 
must ensure that we do not neglect the devel- 
opment of the in-house pool of talent that is al- 
ready available. 

jUH Increase Awareness 

One of the easiest ways to deal with an issue is 
to heighten awareness of the issue among the 
people most affected. This is possible, for ex- 
ample, through articles (such as this one) in 
employee newsletters and technical publica- 
tions, and in briefings to the technical work- 
force (particularly as part of orientation and 
retirement seminars). The personnel who 
comprise the technical work force will deter- 
mine the future viability of NASA. If the is- 
sue is credible and gains grassroots accep- 
tance, then individual actions addressing the 
issue will become a matter of routine rather 
than a result of formal policy. For example, 
the Equal Employment Opportunity (EEO) 
Office at NASA Goddard Space Flight Center, 
Greenbelt, MD, has provided first-line super- 
visors with the opportunity to attend a one- 
day, in-house training program on "Managing 
Age Diversity.” 

■ Support Employee 

Development Programs 


grams constitute an investment by the agency 
in its future that requires commitment at all 
levels of management. A critical element to 
the success of these programs is the support of 
first-line management. These are the manag- 
ers who are in the trenches and who must bal- 
ance the long-term developmental needs of 
their employees (in the interest of the employ- 
ee and the agency) with the near-term de- 
mands of the group activities (in the interest 
of the tasks at hand). 

Most obvious among these programs are the 
continuing and graduate education programs 
that enable NASA employees to pursue de- 
grees of higher education during their em- 
ployment or to enhance their technical educa- 
tion. Less obvious, perhaps, is the "continuing 
education” that occurs when employees attend 
professional and technical meetings where in- 
formation is shared and valuable contacts are 
made throughout the industry. Such activi- 
ties may be viewed as a form of "continuing 
education” for experienced employees, insofar 
as the activity enhances their ability to suc- 
ceed on the job. 

Other NASA programs provide for non- 
academic personnel development. NASA’s 
Professional Development Program (PDP), for 
example, allows selected NASA personnel to 
participate in a one-year developmental pro- 
gram at NASA Headquarters or a NASA Cen- 
ter. The program is intended to provide the 
opportunity for individuals to broaden their 
technical and programmatic experience, as 
well as to gain an understanding and appre- 
ciation of the culture and perspective of other 
organizational elements within NASA. More 
emphasis on inter- and intra-Center assign- 
ments should also be considered. 


While we may be limited in our ability to hire 
additional S&Es, we can and should continue 
to support programs that provide employees 
with opportunities to develop greater techni- 
cal or managerial experience. These pro- 



Documentand Disseminate 
Information 


Valuable information can be lost if adequate 
and timely documentation of technical and 
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managerial information does not occur.? All 
too often, formal documentation does not oc- 
cur until a program or project is either can- 
celled or completed, and "lessons learned” be- 
come "lessons lost” as key employees move on 
to other assignments and personal files are ei- 
ther discarded or sent into storage. 8 

Policies should be established and promoted, 
particularly by relevant program and project 
managers, that facilitate the documentation 
and dissemination of technical and manage- 
ment information. In the case of detailed, 
technical design data, it will also be necessary 
to provide updates to the information base as 
new or revised information becomes available. 


In general, this activity will necessarily in- 
volve the efficient and widespread storage and 
dissemination of information via electronic 
media. On a more immediate level, the mass 
of documentation associated with major pro- 
grams, such as Space Station Freedom, is too 
extensive for any individual to be familiar 
with the bulk of it. 



Establish Deputy Manager Positions 


Nothing provides better experience than on- 
the-job training and experience. One possibil- 
ity for accelerating the management "educa- 
tion” of inexperienced employees would entail 
the official or unofficial establishment and 
promotion of temporary or rotating positions 
for deputies to first-line managers. These po- 
sitions would provide management experience 
for qualified employees, while minimizing the 
risks associated with placing an untrained in- 
dividual in an unfamiliar, and perhaps, in ap- 
propriate role. The non-permanent nature of 
the position would avoid the appearance of a 
demotion when the individuals return to their 
former position, while maximizing the num- 
ber of employees who could benefit from the 
experience. Caution should nonetheless be 
exercised to ensure that such positions do not 
generate an undesirable, and possibly unnec- 
essary, layer of bureaucracy. 


Establish Chief Engineer/Scientist 
Positions 

Within programs and areas of technical exper- 
tise, it is advantageous to the organization to 
maximize the benefits available through the 
experience of senior individuals. This organi- 
zational need can be balanced by the benefit 
accrued to the senior employee who has either 
stagnated on the technical side of the dual- 
career ladder, or who chooses to relinquish su- 
pervisory responsibilities in favor of a more 
technical, non-supervisory role. Ideally, this 
is the situation encountered in establishing 
positions for chief scientists and chief engi- 
neers. These positions would enable a greater 
number of individuals to benefit from exper- 
ienced, non-supervisory S&Es, while provid- 
ing highly-valued S&Es with greater visibil- 
ity and enhanced recognition of their value to 
both the group and the agency. 

Implement Technical 
Mentor Programs 

Although established fresh-out mentoring 
programs exist at several NASA Centers, 
there does not appear to be an agency- wide po- 
sition on mentoring. In some respects, each 
program must necessarily be tailored to the 
personality and culture of the particular Cen- 
ter; however, there should be some program 
characteristics that are common among men- 
toring programs at all the Centers. An exam- 
ple of a Center initiative is the Interactive De- 
velopment of Engineers, Administrators, and 
Scientists (IDEAS) program, at NASA Ames 
Research Center (ARC), Mountain View, CA, 
designed to better integrate new hires into the 
ARC work force through interaction with 
peers and highly regarded senior employees. 
Participant feedback has shown that the long- 
time employees involved in the program claim 
a feeling of revitalization as a result of their 
experiences within the program. 

It is not enough to place an inexperienced in- 
dividual in a position of responsibility, par- 




43 




Age Distribution Among NASA Scientists and Engineers 


ifffff 


TTTT 




ZE 


3 


ticularly on long-term programs, when hard- 
ware will not be produced for some time. A 
pratical understanding of technical principles 
is necessary if success is to be ensured. 


at our disposal will be best directed in areas 
over which we are able to exert the most con- 
trol, such as the development of in-house tal- 
ent. 


We can serve two purposes by facilitating in- 
teractions among experienced, long-time em- 
ployees, and inexperienced fresh-outs or new- 
hires — the new employees are more quickly 
schooled in the culture and history of the orga- 
nization, and technical insight and knowledge 
can be passed along; and the long-time em- 
ployees are presented with fresh, new perspec- 
tives that sometimes break with accepted 
lines of thinking. These interactions could 
take the form of one-on-one pairings that pro- 
vide both technical and cultural mentoring, or 
they could take the form of small, low-cost, 
low-risk technical projects that provide inex- 
perienced personnel with the opportunity to 
acquire invaluable hands-on experience. 


The future promises both challenges and op- 
portunities for the NASA manager. While we 
may hope for the best, we should nonetheless 
plan for the future in order to assure the con- 
tinuity needed for increasingly complex mis- 
sions. 
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The Program and Project 
Management Collection 

A special collection, The Program and Project 
Management (PPM) Collection, has been es- 
tablished at the NASA Headquarters Scienti- 
fic and Technical (S&T) Library. The collec- 
tion is part of the Program and Project Man- 
agement Initiative, sponsored by the NASA 
Office of Human Resources and Organization- 
al Development. 

The S&T Library maintains and lends docu- 
ments from this collection to interested per- 
sonnel through each of the NASA Center li- 
braries. The collection includes books, semi- 
nar proceedings, documents, and videos gath- 
ered from Headquarters and the NASA Cen- 
ters. Some of the materials include: 

► Books 

Project Management: A System Approach 
to Planning. Scheduli ng and Controlling by 
Harold Kerzner, 1984. 

Management: Tasks, Responsibilities, 

Practices by Peter Drucker, 1974. 

Computer Models for Operations Manage- 
ment by Owen P. Hill, Jr., 1989. 

Beyond the Atmosphere by Homer Newell, 
1981. 

Issues in NASA Program and Project Man - 
agement , (NASA SP-6101) 1988 and 
(NASA SP-610K02)) 1989. 

^ Documents 

Getting on Contract , JPL D-1844, Rev. C 
October 1987. 



Management Directives Relevant to Typi- 
cal Phase A, Phase B, and Phase C/D Re- 
quest for Proposals , Marshall Space Flight 
Center, Revision E, July 1987. 

Technical Managers Handbook , Engineer- 
ing Directorate, Goddard Space Flight Cen- 
ter, May 1989. 

► Videos 

Introduction to Project Management, 
IEEE, Parts 1- 4, 1982. 

Shared Experiences in NASA Projects , An- 
gelo Guastaferro, April 21, 1989. 

Project Management at Johnson Space Cen- 
ter , Aaron Cohen, December 7, 1989. 

Explorer Satellites Program: Shared Ex- 
periences , Gerald Longanecker, September 
1989. 

^ Proceedings 

NASA Colloquium on Project Manage- 
ment , 1980. 

Project Management Institute Seminar/ 
Symposium, Several years running. 


Materials from the PPM Collection are acces- 
sible at each Center Library using the Aero- 
space Research Information Network (ARIN). 
ARIN is an online catalog to which all of the 
NASA libraries contribute on a daily basis. 
Any book added to a NASA library collection 
can be located through the use of ARIN. Much 
like a card catalog, ARIN may be searched by 
title, author, or subject. The advantage of an 
online system is its keyword searching capabi- 
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lities. All of the materials in the PPM Collec- 
tion have been "tagged” with a special code. 
Using that special code in a keyword search 
will display every title in the collection. 

For example, to see a list of all the titles from 
the collection, enter K = XPMX. Enter the line- 
number to see the entire entry. You may 
want to print the screen if you think the title 
is of interest. To return to the list of titles, en- 
ter the letter i. 

Because there will be many titles in the entire 
collection you may want to limit your search 
by subject: 

K = XPMX SYSTEMS ENGINEERING 

or you may know when a document was pub- 
lished. Enter: 

K = XPMX 198$ 

An author search may be entered like this: 

K = XPMX CLELAND 

There are many variations on keyword 
searching. Ask your librarian for assistance. 

The request will be handled quickly if you 
have a title, author and call number, such as 
"T56, 8 N37 1989.” The request will be for- 
warded to the NASA Headquarters S&T Li- 
brary. After identifying the materials you 
want to borrow, please relate pertinent infor- 
mation to the reference desk at your NASA 
Center library, which will expedite the re- 
quest and get the material to your library as 
soon as possible. You may keep the material 
for one month. Exceptions will be considered 
on an individual basis. 

Additional questions concerning the collection 
may be addressed to Char Moss, at FTS-453-, 
or (202) 453-8545, who welcomes suggestions 
from users on how to improve the collection 
and what could be added. Donated materials 
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— books, documents, videos, or proceedings — 
are always needed. If you have any useful ma- 
terials that would be of value or interest to 
NASA management, forward them to the 
Headquarters S&T Library where they can be 
processed and made available to others. Out- 
of-print books on NASA management and his- 
torical reports on "lessons learned” from 
NASA projects are particularly in demand. 
Keep in mind that this collection is useful not 
only for current NASA managers but also the 
next generation of NASA managers as they 
learn from the past and prepare for the future. 


I A Crash Course in Defining 
'Systems Engineering’ 

Back on September 27, 1968, a NASA engi- 
neer by the name of George S. Trimble wrote 
to the Chief of the Management Analysis and 
University Programs Office after the Chief is- 
sued a letter to find a universally suitable 
definition for "systems engineering.” The en- 
gineer told the manager that the term had no 
particular meaning at all. "In fact,” Trimble 
claimed, "I may know the guy who thought it 
up or resurrected it, as the case may be, for 
modern usage.” His seemingly authoritative 
account follows: 

"During the war, new management practices 
were introduced at a great rate, and one of the 
functions that came to the fore was the busi- 
ness of writing job descriptions and evaluat- 
ing them. Certain industrial relations experts 
fell heir to this function, and there was a ten- 
dency for them to write very clear job descrip- 
tions for all jobs except their own. It soon be- 
came obvious that the value of a job, or, more 
importantly, the money it paid (or even more 
importantly, its draft-dodging power), was in- 
versely proportional to the ease with which 
one could describe it. Industrial relations peo- 
ple were able to describe any engineering job 
in 25 words or less, whereas an industrial re- 
lations function might take two or three 
pages. Although miserable to begin with, en- 
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gineering salaries were threatened and so was 
draft status. 

"Of course, everyone knows that engineers are 
very creative. They could see that the indus- 
trial relations boys had a good thing going, so 
they borrowed the approach and improved on 
it (typical engineering method). 

"Soon it took five pages to describe the most 
menial engineering task, and the engineers 
were saved. It was a simple matter to spend 
three hours explaining to a job analyst from 
industrial relations why a 'systems engineer- 
ing’ blueprint file was much more complicated 
to run than a simple old 'engineering’ blue- 
print file, which was, of course, familiar. The 
guy from industrial relations never did under- 
stand it because the guy who explained it, 
didn’t. It takes a lot of words to explain some- 
thing you don’t understand or that isn’t there. 
Try explaining 'zero’ sometime. 

"A parallel effort with the objective of empha- 
sizing *!! ENGINEERING !!* was carried out 
with great dispatch by the 'scientists,’ all of 
whom became famous at the close of WWII be- 
cause a couple of them single-handedly in- 
vented and built the A-bomb, all by them- 
selves, with great secrecy. What they were 
really doing all that time, of course, wasn’t 
science — it was engineering. When this was 
discovered, a mixed wave of nausea and terror 
ran through the brotherhood. It was worse 
than being caught reading a dirty book in 
church. Most learned scientists knew that en- 
gineers were people who ran around with spe- 
cial hats and oil cans and made steam locomo- 
tives go, and who, incidentally, made too 
much money. Being identified as part of the 
same crowd was too much for the intellect to 
bear. Scientists had to be working on some- 
thing more important than 'engineering’ 
which is supervised by a Ph.D. and is there- 
fore high-class and also obvious to those 
schooled properly, but difficult if not impossi- 
ble for anybody else to understand. 


"Since, as we all know, very few, if any, Ph.Ds 
understand the meaning of plain, ordinary 
'engineering,’ it follows that 'systems engi- 
neering’ has given engineering a bad name, 
and should be avoided for that reason alone. 

"A third group who helped the cause for sys- 
tems engineering were the pre-war 'handbook’ 
engineers who discovered creative engineer- 
ing when they joined up with a wartime in- 
dustrial engineering group to avoid being 
drafted. They had always thought that 'engi- 
neering’ was the choosing from a catalog of 
the proper washer for a quarter-inch bolt. It 
was difficult for them to use the same name 
for their new discovery, creative engineering 
( designing a washer for a quarter-inch bolt). 
The term 'systems engineering’ suited well, 
and groups of people were noising it around by 
then. It sounded nice and, after all, a quarter- 
inch bolt is a fastening system of high com- 
plexity. It consists of a bolt with threads (heli- 
cal inclined plane), a nut of the proper size, 
hand and thread configuration (bolt interface 
problem), external shape (wrench interface 
problem), one or more washers (structures in- 
terface problem), and sometimes even a cotter 
pin (reliability). 

"Moreover, one could dream of performing 
systems engineering at increased hierarchical 
levels by considering at one and the same time 
not only the quarter-inch bolt, but also the 
half-inch bolt. Advanced systems engineer- 
ing. 

"So much for the history and meaning of sys- 
tems engineering. You can demonstrate the 
validity of my story to yourself in several 
ways. Your letter can be clarified by eliminat- 
ing the word 'systems.’ I believe it appears 10 
times. Check the universities for courses in 
systems engineering and find out what they’re 
really teaching. Note also that the term 'sys- 
tems engineering’ does not yet appear in a an 
accredited dictionary. This is because Web- 
ster can’t figure it out either. Good luck.” 
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Well, that was the extent of definition history, 
according to engineer George Trimble in 1968. 
But what about today? Is "systems engineer- 
ing” a set, definable term in the dictionary to- 
day? First stop, American Heritage Dictio- 
nary — no listing for "systems engineering.” 

Second stop, a Webster’s. Indeed, the grand- 
daddy of all dictionaries has it listed as an 
"Americanism,” a term indigenous to this 
country. It reads: 

systems engineering, a branch of 
engineering using esp. information 
theory, computer science, and facts from 
systems analysis studies to design 
integrated operational systems for 
specific complexes. 

All well and good, you suppose, but 
whatexactly is "information theory” following 


the "esp.”? Turn back 722 pages and you find: 

information theory, the study of pro- 
cesses of communication and the trans- 
mission of messages; specif., the study 
dealing with the information content of 
messages and with the probability of 
signal recognition in the presence of in- 
terference, noise, distortion, etc. 

The "etc.” may be imprecise, but just when 
you think you are getting a handle on an up- 
to-date definition of "systems engineering” 
which has something to do with "information 
theory,” you get thrown off by another term: 
"signal recognition.” Not to worry, right? Be- 
cause you can always look up that fuzzy term 
for a clear, concise definition. But guess what: 
"signal recognition” is not in Webster’s (nor is 
it in American Heritage Dictionary). Mr. 
Trimble may have been right all along. 


BOOK REVIEWS 


Project Management Body of 
Knowledge (PMBOK) 

by PMI Standards Committee 
(Drexel Hill, PA: Project Management 
Institute, 1987) 



The hundred or so pages of PMBOK covers 
nine areas of concentration: PM Framework 
(Philip Nunn), Scope (Richard Cockfield), 
Quality (William Dixon), Time (Joe R. Beck), 
Cost (Peter G. Georgas and George Vallance), 
Risks (David V. Pym), Human Resources 
(John R. Adams and Linn C. Stuckenbruck), 
Contract/Procurement (Shakir Zuberi), and 
Communications Management (Shirl Hol- 
ingsworth), plus an essay by R. Max Wideman 
on PMBOK Standards and a glossary. 


PMBOK was developed by a PMI Committee 
in 1983 as an effort to describe and define the 
knowledge necessary to function adequately 
as a Project Management Professional. As 
such, it became the official PMI basis for certi- 
fication exams and review of graduate pro- 
grams in September of 1988. 

The effort itself was well thought out. Pur- 
poses were to organize and classify in 
PMBOK; to integrate, correlate, store, and re- 
trieve, and "build on what we have.” Charac- 
teristics of the effort had to be simple, logical, 
saleable, comprehensive, compatible, system- 
atic, and understandable. As areas were 
carved out, they were published in the Project 
Management Quarterly (now Journal). 

Stuckenbruck, in an overview section, illus- 
trates the basic project management elements 


48 



Resources 


and functions in a matrix model which resem- 
bles this: 


Project 

Management 

Functions 


Planning and 
Control 


Project 

integration 


Resources 


Risk 


Human 

Resources 


Contacts and 
Procurement 


information 

and 

Communicatio 


Project Management Matrix Model 

Wideman suggests that a simpler Work 
Breakdown Structure (WBS), defined as a 
task-oriented tree of activities, "is too restric- 
tive for purposes of representing the 
PMBOK,” so the matrix model serves as the 
framework for discussion of the PMI approach 
to a project management body of knowledge. 

Wideman traces the effort to produce a body of 
knowledge on project management to 1976. 
The main concerns then were standards, certi- 
fication, accreditation, and a code of ethics to 
establish project management as an indepen- 
dent profession. By 1986, the PMI project 
#121 had settled on a working definition: "A 
project is any undertaking with a defined 
starting point and objectives by which comple- 
tion is identified. In practice, most projects 
depend on finite or limited resources 


Project Elements 

Scope Quality Scheduled Cost Environment 



by which the objectives are to be accom- 
plished.” 

PMBOK is nicely printed with foldout charts 
and diagrams in a looseleaf binder. As the 
discipline or standards of project management 
change, modified pages can be inserted easily. 
And as the distinct profession of project man- 
agement evolves, pages can be added. 
PMBOK thus represents a strenuous effort on 
the part of prominent management theorists 
in the U.S. and Canada to reduce the common- 
ly accepted essentials of project management 
knowledge into one short, easy-to-read binder 
with useful glossaries and references at the 
end of each section. 

■ The Management of Research 

Institutions: A Look at Government 
111 Research Laboratories 

by Hans Michael Mark and Arnold Levine 
(NASASP-481. Washington, D.C.: 

U.S. Government Printing Office, 1984) 

Starting with the assumption that "the great- 
est strength of the technology development 
laboratory is in basic and applied research 
and not (with rare exception) in product devel- 
opment,” physicist Hans Mark and social sci- 
entist Arnold Levine set out to analyze large 
research institutions constrained by normal 
financial limitations. For example, how does 
a manager do medium- and long-range plan- 
ning on an annual funding cycle? 

Following a brief historical overview from the 
Lyceum of Aristotle and Plato to the founding 
of the British Royal Society, the authors focus 
on the past two decades of NASA, DoD, and 
the Nuclear Energy Development Center. 

The "ultimate reality” for the authors are pro- 
jects themselves, leading to some "practical” 
applications of technology development. The 
use of project methods is nothing new — re- 
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call the six-month construction of the Monitor 
in 1862, the Manhattan Project, and the Apol- 
lo Program. However, "the project approach 
sometimes entails heavy penalties when it is 
pushed to the exclusion of other approaches 
and becomes a brute force effort to achieve a 
goal, or freezes technology prematurely.” No 
better example serves them than Apollo, with 
lunar landing as a "dead end.” Had NASA se- 
lected "earth-orbit rendezvous initially, the 
lunar landing could still have been achieved 
and NASA would have had at least a ten-year 
start on deploying an orbiting space station, 
rather than waiting until 1982 to let study 
contracts for its design.” The authors contrast 
the "single-minded” Apollo program with the 
"open-ended and continuing” Shuttle Pro- 
gram and suggest that the Project Approval 
Document (PAD) may no longer be possible 
for NASA in some projects, due to their com- 
plexity. 

The authors make several assumptions about 
the management of professional staff in large 
research institutions. First, "there are no per- 
sonnel policies which are guaranteed to work 
across organizational lines.” Such policies as 
continuing education, indefinite or term em- 
ployment, and rotating work assignments 
may or may not work, depending on the orga- 
nizational culture. Rather, they see personnel 
issues as "synonymous with the organizations 
goals.” They quote Arnold Deutsch to the ef- 
fect that technical people are best motivated 
by the challenge of the work itself, as inspired 
by the institution’s environment. The steady 
decline in large research institutions suggests 
to the authors that they will change little but 
also that an older work force will not mean ob- 
solescence if the institution can transform sci- 
entists and engineers into managers. 

Can they? In a case study, the authors point 
to NASA in the 1970s. Yes, scientists and en- 
gineers can and do make good managers when 
their loyalties are more to the organization- 
than to their technical discipline. Many are 


called to internships and supervisory training 
programs, but few are chosen because of "a 
narrowly, technical education,” these authors 
conclude. 

The Management of Research Institutions is 
amply illustrated with charts, illustrations, 
and case studies, ending with an assertion 
that the most precious of all qualities is the 
human imagination, which enabled even 
Andrei Sakharov to withstand stifling. 
Imagination is best freed in a decentralized 
system "where decision-making is not mono- 
lithic but yet is well enough organized to 
make the importance of science and technol- 
ogy felt.” 


Ilf Organizing for Project Management 

by Dwayne P. Cable and John R. Adams 
(Drexel Hill, PA: Project Management 
Institute, 1986) 

This 34-page monograph is described as a 
"concise yet readable” introduction to or re- 
fresher in organizational alternatives. It is 
not a guidebook or manual, but rather a brief 
description of standard organizations on a 
scale of no or low to high project managerial 
authority: functional, expeditor, coordinator, 
weak matrix, strong matrix and fully projec- 
tized structures. Expeditor and coordinator 
are described as subsets of functional organi- 
zation, and the "fully projectized” organiza- 
tion is defined as one in which the project 
manager has total responsibility, with all the 
personnel needs assigned to that one project. 

The differences in structure and authority are 
spelled out in a series of organizational charts, 
including one repeated 10 pages later. Of 
course, as the authors point out, "few large or- 
ganizations involved in multiple projects use 
any single form of organization” in pure form, 
but selection of the best chart may be "an 
enormous step from which there may be no re- 
turn.” 


50 


Resources 


TTTT 


n 


While most of the outline and description 
would be "old hat” to the seasoned or schooled 
project manager, the authors do list 22 advan- 
tages and disadvantages of a matrix organiza- 
tion form. Particularly interesting is a section 
on "Matrix Pathologies.” They include Power 
Struggles, Anarchy, Groupitis (confusing ma- 
trix behavior with group decision making), 
Collapse During Economic Crunch, Excessive 
Overhead, Decision Strangulation (caused by 
too many administrators), Sinking (when ma- 
trix structure falls to lower management lev- 
els), Layering (matrices within matrices), and 
Navel Gazing (absorbed with internal oper- 
ations to the detriment of the world outside 
the organization). 


Team Building for Project Managers 


by Linn C. Stuckenbruck and David Marshall 
(Drexel Hill, PA: Project Management 
Institute, 1988) 


on performance, using a team reward system 
(such as visibility or recognition), encourag- 
ing professional development (papers, work- 
shops, and special training opportunities), en- 
couraging healthy competition, and providing 
a good environment for a wholesome place to 
work with all the tools and support necessary 
to excel. Clear and effective communication 
are basic in such remedies. That is not to say 
"team building” is a cure-all. The authors say 
no amount of teamwork will save a project if 
the project concept is faulty. Also, the lack of 
top management support can undermine any 
efforts towards team building. Finally, no 
amount of team building will save hopelessly 
unproductive people nor a hopelessly inept 
manager. 

Nevertheless, the authors insist that "team 
building can very well be the most important 
aspect of the project manager’s job,” and this 
50-page booklet is a good start in the process. 



U.S.C. Professor Stuckenbruck and his re- 
search assistant suggest that "team building” 
is at the very core of project management, per- 
haps even more important than technical 
knowledge. 

"Even the best projects using the best tools are 
not immune to failure,” they say, claiming 
that most troubled projects require "team 
members to work together and provide out- 
standing group performance.” 

To accomplish such team building, the au- 
thors say "the cookbook approach” to manage- 
ment, a recipe of tools and techniques, won’t 
work for projects, nor for a losing football 
team. A project is "losing” or sick when there 
are signs or symptoms of frustration, conflict, 
and unhealthy competition, unproductive 
meetings, or lack of confidence in the project 
manager. An alert manager will turn the sit- 
uation around by presenting the problem as a 
challenge, giving regular review and feedback 


■ Roles and Responsibilities of the 
Project Manager 

by John R. Adams and Bryon W. Campbell 
(Drexel Hill, PA: Project Management 
Institute, 1988) 

In a mere 30 pages, the authors attempt to de- 
scribe the functions of a typical project man- 
ager, as well as the education and experience 
needed for effectiveness. As such, these topics 
are merely touched upon, making the booklet 
a very broad overview of a few basic, common- 
ly accepted generalizations. 

However, the PMI booklet does contain a few 
fresh topics on conflict resolution, derived 
from a 1979 book co-authored by Adams. Con- 
flict over planning, organizing, and control- 
ling occur frequently over the span of a proj- 
ect, and the authors suggest five resolution- 
strategies. Most common is "confrontation,” 
whereby the two parties face the problem di- 
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rectly and work together toward a workable 
solution. "Compromise” is a second method, 
involving give and take. Another important 
method, they suggest, is "smoothing” where 
differences are played down and areas of 
agreement are given the most attention. 

Fourth is "forcing” a win-lose agreement, 
where the project manager exerts power to im- 
pose a solution. The least used is "withdraw- 
al” or when one or both parties backs down 
and gives up the conflict for the sake of the 
project. The point is: the project manager is 
expected to manage even conflict situations in 
one of the five ways as part of the demanding 
job. 

"Experience is irreplacable as a learning tool 
for managing people in a project, ” the authors 
assert, but formal education in management 
is also desirable to complement a manager’s 
technical expertise. Typically, such a comple- 
ment would be an MBA degree, although they 
also suggest formal education in such areas as 
psychology, labor relations, and law, plus in- 
formal workshops in communication, group 
dynamics, leadership, and, of course, conflict 
resolution. 


Skill in Communication: A Vital 
Element in Effective Management 

by David D. Acker (Defense Systems 
Management College, Fort Belvoir, VA: 

U.S. Government Printing Office, 1985) 

David Acker spent two decades with Rockwell 
n the Autonetics Division before becoming a 
>rofessor of management at the Defense Sys- 
em Management College. He asserts that 
good communications are the source of good 
management, and skill in communications is 
essential to every other management skill.” 



Interactive communication is needed in any 
organization, he says, for task coordination, 
problem solving, information sharing, and 
conflict resolution. The manager, before com- 
municating, must have a purpose, know the 
audiences’ needs, select the right channel or 
medium, and expect a specific kind of feed- 
back. It sounds elementary, but these are use- 
ful reminders. 

Skills in presentations (public speaking), lis- 
tening, reading, writing, and conducting 
meetings are outlined from a managerial 
point of view. Short chapters on non-verbal 
communication, communication barriers, and 
communication theory round out this handy, 
pocket-size booklet of 86 pages. 

While there is no attempt to provide depth, 
the author does throw up some bewildering 
terms like "kinesics” (related to something 
called "movement analysis”), "paralanguage” 
(not defined), and "noise barrier” (defined 
mysteriously as "any communication problem 
that can’t be fully explained”). Nevertheless, 
its brevity is the booklet’s strength. This 
booklet is a storehouse of useful tips to refer to 
before a manager is called upon to speak, 
present, read, write, or listen. 

One insightful term which keeps popping up 
in Skill in Communication is "empathy.” 
Acker suggests that the speaker or author 
"can put yourself in the receiver’s place and 
analyze the message from his viewpoint.” A 
disclaimer in a footnote explains, but does not 
justify, that the author is using the male ad- 
jective as a literary term, in a generic sense. 
Rhetoricians are saying now that the use of 
sexist language is inexcusable. A sentence 
that calls for a personal (male) pronoun is, 
more often than not, a poorly constructed sen- 
tence anyway. 
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